BEA White Paper A BEA Enterprise Architecture Guide Creating SOA from a Monolithic Portal Environment
Copyright Copyright 1995-2006 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This software is protected by copyright, and may be protected by patent laws. No copying or other use of this software is permitted unless you have entered into a license agreement with BEA authorizing such use. This document is protected by copyright and may not be copied photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form, in whole or in part, without prior consent, in writing, from BEA Systems, Inc. Information in this document is subject to change without notice and does not represent a commitment on the part of BEA Systems. THE DOCUMENTATION IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, BEA SYSTEMS DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE DOCUMENT IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. Trademarks and Service Marks Copyright 1995-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
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 interoperable, standards-based services that can be combined and reused quickly to meet business needs. IT and lineof-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 to strategic goals can be problematic. The success of an SOA implementation depends on the ability to implement transitional architectures over weeks and months yet preserving goals which may take a period of years to achieve completely. With SOA, IT can remain agile, staying close to business requirements over the course of successive changes and enhancements. Treat the service infrastructure as a toolbox. The service infrastructure is the first of the critical capabilities that determine the success of an SOA. Over time, the service infrastructure should provide the ability to add new tools to an environment that complement existing tools and provide new capabilities without necessitating rework or affecting other tools already in use. This allows an architecture to mature over time and 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
Achieving the strategic goals of SOA Getting started To 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 challenge 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 db Mainframe.Net ERP Data Warehouse 2
Step 1: decoupling of data logic Decoupling of the architecture s data logic is the first step in transitioning from a monolithic portal to a SOAbased 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 the data 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 can make physically merging data difficult or even impossible. The ability to perform dynamic data transformation since data from disparate sources and environments rarely are homogeneous in format or accessibility. The ability to handle security through data redaction and participation of data security in the larger enterprise 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 requirements in weeks rather than months and remove programmer expertise or availability as potential bottlenecks. Figure 2 The Data Service layer enables abstaction and de-coupling of the Presentation Business Data layer from the physical data feeds. Presentation Business Data Data Services Layer db Mainframe.Net ERP Data Warehouse 3
Step 2: controlling service proliferation As 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 satisfactorily 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 searched without the need for coding changes. Mapping a Service Registry to an organization s specific requirements improves 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 published business services for one-step approval. This dramatically simplifies new service publication and can notably improve the rate of service contribution. Standards support: The registry should support industry standards such as the UDDI v3 standard, including support for subscriptions and automatic notifications of changes to Web services. Policy support (publication and assignment): The registry should publish and associate policies in compliance with service level agreements. WS-Policy Attachments: This enables policy reuse, improving efficiency and reducing risk; it also ensures consistency in an organization s SOA. Federation should be supported through UDDI-level replication. Figure 3 Enterprise architecture after the addition of a service registry. Presentation Business Data Data Services Layer Service Registry db Mainframe.Net ERP Data Warehouse 4
Step 3: loosely coupling consumers from producers Although services have been created at this point in the process, the architecture still has tightly coupled pointto-point services. Moving to a more loosely coupled environment will improve agility and prevent the development 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 inexpensive 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 support complex routing steps. Support for both point-to-point and one-to-many routing scenarios, enabling both request-response and publish-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-xml data, 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. Figure 4 Service infrastructure after the addition of an enterprise service bus. Presentation Business Data Enterprise Service Bus Service Registry Service Registry Data Services Layer db Mainframe.Net ERP Data Warehouse 5
Dynamic message transformation. Dynamic service selection based on message content or headers, with the ability to transform messages based 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 on performance. 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 consumption available via WSRP-allowing developers to treat presentation as a service. Users Figure 5 Inner design patterns of WSRP implementation. Portal (consumer) http/https Community of interest SOAP over http/https http/https Portal (consumer) SOAP over http/https Portal (producer) Web Service (producer) 6 Enterprise Community of interest
Figure 6 Service infrastructure with business services. Presentation Business Data Business Management Service Registry Enterprise Service Bus Service Registry Data Services Layer db Mainframe.Net ERP Data Warehouse 7
Step 5: consuming other services Once WSRP Services are available in a given architecture, one gains the ability to consume presentation artifacts 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 enterprise 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. Figure 7 Consumption of.net application into BEA WebLogic portal. BEA WebLogic Portal Framework WSRP BEA Portal.NET Application Accelerator REST.NET Control.NET Web Form 8
Conclusion The 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 tactically, 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 initially set in place. About BEA BEA 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 community At BEA, we understand that developers need different kinds of resources than IT managers. And that architects face different challenges than executives. That s why we ve created four unique communities that give you exclusive access to a formidable group of your peers, to a world of shared thinking, and to the kind of meaningful 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
BEA Systems, Inc. 2315 North First Street San Jose, CA 95131 +1.800.817.4232 +1.408.570.8000 bea.com CWP1478E1106-1A