Concepts and Architecture

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Introduction

This section briefly discusses the current focus on service-driven IT strategies, key business drivers for Service-Oriented Architecture (SOA) initiatives and the strategic significance of an Enterprise Service Bus (ESB) component. It provides a conceptual overview of BEA AquaLogic Service Bus infrastructure solution and functional capabilities that distinguish it as an SOA success factor. It is intended for management stakeholders responsible for SOA initiatives, integration-focused IT architects, service modelers or designers, and system administrators.

The following topics are included in this section:

 


Service-Oriented IT Trends

In today’s highly competitive global market, businesses operate in a very liquid environment in which information is the most strategic asset. Responding rapidly to changes in competition, market dynamics, and regulatory mandates, with timely information, is critical for the effective functioning and overall success of businesses. To meet rapidly changing market demands, businesses have become increasingly service-driven, both in the ways they interact with customers and partners, and in how they design and build their IT infrastructure.

As businesses strive to deliver ROI through increased agility and responsiveness, they depend on enterprise IT groups to find new and cost effective means to deliver new services and to promote the free flow of information and business processes within the organization. The following business drivers have made service-oriented IT architectures an economic reality in today’s enterprise:

Service-Oriented Architecture

Service-Oriented Architecture (SOA) has emerged as the leading IT agenda for infrastructure reformation, to optimize service delivery and ensure efficient business process management. Part of the paradigm shift of SOA are fundamental changes in the way IT infrastructure is designed—moving away from an application infrastructure to a converged service infrastructure. Service-Oriented Architecture enables discrete functions contained in enterprise applications to be organized as layers of interoperable, standards-based shared “services” that can be combined and reused in composite applications and processes.

In addition, this architectural approach also allows the incorporation of services offered by external service providers into the enterprise IT architecture. As a result, enterprises are able to unlock key business information in disparate silos, in a cost-effective manner. By organizing enterprise IT around services instead of around applications, SOA helps companies achieve faster time-to-service and respond more flexibly to fast-paced changes in business requirements.

In recent years, many enterprises have evolved from exploring pilot projects using ad-hoc adoption of SOA and expanded to a defined repeatable approach for optimized enterprise-wide SOA deployments. All layers of an IT SOA architecture have become service-enabled and comprise of presentation services, business processes, business services, data services, and shared services.

Figure 1-1 SOA Conceptual Architecture

SOA Conceptual Architecture

Service Mediation Challenges

A major challenge for SOA initiatives is attributed to the inherently heterogeneous multi-vendor IT landscape in many enterprises, and the resultant individual silos of business information. Rather than incur the cost and complexity of replacing disparate components of legacy infrastructure, enterprises often choose to extend existing business applications as services for use in other business processes and applications.

The influx of Web service interfaces to functionality within existing packaged applications, often introduces services that do not adhere to established service and compliance guidelines. This is especially true if the services are published from core enterprise systems such as CRMs, Data Warehouses, and ERPs.

In the absence of robust and comprehensive service infrastructure solutions, developers have used a variety of “middleware” technologies to support program-to-program communication, such as object request brokers (ORBs), message-oriented middleware (MOM), remote procedure calls (RPC). More recently, IT infrastructure developers hard-coded complex integration logic as point-to-point connections to web services, in order to integrate disparate applications and processes. This inevitably resulted in complex service sprawls within enterprise IT environments. The following figure illustrates a typical static service integration scenario.

Figure 1-2 Service Sprawl Challenge

Service Sprawl Challenge

The following are other service related challenges attributed to heterogeneous IT architectures:

Enterprise architects and web service modelers with goals to streamline IT infrastructure now require enterprise service capabilities that address the following IT needs:

Composite Applications and Service Layering

In an SOA initiative, composition is an integral part of achieving business flexibility through the ability to leverage existing assets in higher-order functions.Within a mature SOA environment, complete business applications are composed using existing services to quickly meet the business needs. Flexibility in the service provisioning process, is achieved by avoiding coding logic in service implementations.

Many organizations develop services at very granular levels and the proliferation of many small specific services are difficult to compose into broader logical services. Layering of Services is as a way of breaking out of the limitations of monolithic applications and shortening development, release and test cycles. By defining a layered approach to service definition and construction, the service infrastructure team can achieve the right mix of granular and course-grained services required to meet their current and future business demands.

Service Layers typically comprise of the following services:

Service Bus Component of SOA

The core of SOA success depends on an Enterprise Service Bus (ESB) that supports dynamic synergy and alignment of business process interactions, continual evolution of existing services and rapid addition of new ones. To realize the benefits of SOA, it is imperative that IT organizations include a robust and intelligent service intermediary that provides a layer of abstraction to mask the complexities of service integration in heterogeneous IT environments, typical in today’s enterprises. While an intermediary layer of abstraction previously implied a platform for customizing enterprise applications, today it implies toolkits for service customization and scalable infrastructures that support loosely coupled service interactions with a focus on service mediation.

Figure 1-3 Enterprise Service Bus

Enterprise Service Bus

ESBs have been instrumental in the evolution of integrated middleware infrastructure technology by combining features from previous technologies with new services, such as message validation, transformation, content-based routing, security and load balancing. ESBs use industry standards for most of the services they provide, thus facilitating cross-platform interoperability and becoming the logical choice for companies looking to implement SOA.

An ESB provides an efficient way to build and deploy enterprise SOA. ESB is a concept that has gained the attention of architects and developers, as it provides an effective approach to solving common SOA hurdles associated with service orchestration, application data synchronization, and business activity monitoring. In its most basic form, an ESB offers the following key features:

More advanced ESBs typically offer a number of additional value-added features, including:

Using ESBs offers greater flexibility for enterprises to connect heterogeneous resources, by eliminating the need for brittle high-maintenance point-to-point connections. Adding an ESB intermediary between service consumers and service providers, shields them from the implementation details of underlying service end-point interfaces, reducing or eliminating the redevelopment and redeployment impacts at the service-consumer level.

Best in class enterprises have achieved SOA success by harnessing high-speed enterprise-ready ESB intermediaries that strategically integrate service mediation capabilities and business process management functionality. Recognizing the significance of operational service management as a critical SOA success factor, they have implemented solutions that provide enterprise-class service scalability, reliability, customization and security. By adopting such solutions built specifically for management and governance of an SOA service lifecycle, these enterprises have obtained the following business benefits:

 


BEA AquaLogic Product Suite

BEA AquaLogic is the first service-infrastructure product family built from the ground up for Service-Oriented Architectures, giving IT a unified set of products to successfully deploy an SOA across their organization and achieve better business agility and IT efficiency.

Figure 1-6 AquaLogic Service Bus Shared Services Product Architecture

AquaLogic Service Bus Shared Services Product Architecture

The following product lines are available within the BEA AquaLogic product family:

 


BEA AquaLogic Service Bus

BEA AquaLogic Service Bus is a proven market-leading Enterprise Service Bus (ESB) built from the ground up for SOA lifecycle management that provides foundation capabilities for service discovery and intermediation, rapid service provisioning and deployment, and governance. This service-infrastructure software adheres to the SOA principles of building coarse grained, loosely coupled, and standards-based services, creating a “neutral container” in which business functions may connect service consumers and back-end business services, regardless of underlying infrastructure.The following figure illustrates the role of BEA AquaLogic Service Bus as a service intermediary in an enterprise IT SOA landscape:

Figure 1-7 AquaLogic Service Bus Intermediary

AquaLogic Service Bus Intermediary

Built to meet exacting standards for reliability, availability, scalability, and performance, BEA AquaLogic Service Bus uniquely combines the integration capabilities of an Enterprise Service Bus with operational service management, into a single enterprise-class software product, with a layered functional architecture.

Figure 1-8 AquaLogic Service Bus Functional Features

AquaLogic Service Bus Functional Features

The functional features of AquaLogic Service Bus can be categorized into the following functional layers:

Significance in an SOA Landscape

BEA AquaLogic Service Bus is at the heart of BEA’s comprehensive business integration solution and belongs to the BEA AquaLogic Messaging product line. BEA AquaLogic Service Bus is primarily targeted for managing different types of services, and providing traditional message brokering across heterogeneous IT environments. The lightweight, stateless, high-performance architecture of AquaLogic Service Bus and its converged intelligent message mediation and service lifecycle management capabilities, make it an ideal core component of distributed services networks. It is designed to fit into the broader IT Service-Oriented Architecture (SOA) landscape as a distributed service management intermediary and can be integrated with other BEA business process management solutions in distributed heterogeneous deployments.

Figure 1-9 AquaLogic Service Bus Significance in SOA Architecture

AquaLogic Service Bus Significance in SOA Architecture

AquaLogic Service Bus Use Cases

AquaLogic Service Bus is a powerful lightweight, cost-effective technology that can be used by service developers and architects for the following use cases:

AquaLogic Service Bus and the Service Lifecycle

The lifecycle of a service comprises of the following two phases:

AquaLogic Service Bus plays an integral part in the service lifecycle run-time phase. It facilitates the following important functions in the services lifecycle:

Role of AquaLogic Service Bus in a Service Cycle

A key design philosophy of AquaLogic Service Bus is the physical separation of management functions from service implementations. As part of an enterprise's messaging fabric, AquaLogic Service Bus can be used horizontally integrate many applications and systems, spanning service implementations in different departments built by different teams.

As services are created, they are registered and exposed for later consumption by other services or processes. Services can be registered directly with AquaLogic Service Bus in its local service registry, or imported from an enterprise service registry such as the BEA AquaLogic Service Registry. After services are registered with AquaLogic Service Bus, it configures proxy interfaces that define the message flow for communicating with these services.

This flow contains any transformation and security requirements that must be applied, as well as specifications for routing the message to the service. After services are registered with AquaLogic Service Bus, business processes, such as those created with BEA WebLogic Integration, can consume these services and orchestrate them to support various business contexts. These orchestrated processes define how the services are used and applied to business requirements and fine-grained business processes. These business processes are then exposed for use by end users through a user interface (UI), which could be a transactional portal such as BEA WebLogic Portal or a collaborative portal such as BEA AquaLogic Interaction.

BEA AquaLogic Service Bus again steps into the lifecycle to monitor and manage message flow, system health, and availability between service end points. This information may be reported to business and operations analysts who can analyze it for patterns of behavior indicating where improvements should be made. The lifecycle begins again as services evolve over time and new versions are released.

Functional Features and Benefits

The key functional capabilities in the AquaLogic Service Bus can be classified into the following functional layers:

Adaptive Service Messaging Layer

BEA AquaLogic Service Bus supports an unprecedented level of heterogeneity and can reliably connect any service by leveraging standards. Existing middleware, applications, and data sources become first-class citizens of SOA initiatives, protecting existing IT investments and enabling IT to connect, mediate, and manage services using heterogeneous end points, formats, and protocols.

Figure 1-11 Adaptive Service Messaging Layer

Adaptive Service Messaging Layer

AquaLogic Service Bus works with diverse Web Services transports including the following:

AquaLogic Service Bus includes support accepting SOAP 1.1 messages and converting them to SOAP 1.2 messages when necessary to invoke a SOAP 1.2 business service, and vice versa on the following platforms:

AquaLogic Service Bus promotes efficient message orchestration by working with traditional messaging protocols and messaging paradigms. For a complete list of supported protocols and communication paradigms, see Service Integration, topics Transport Protocols and Messaging Models.

In addition to its industry-leading support for Web services, AquaLogic Service Bus also provides native connectivity to MQ Series, CICS, .NET, C/C++ applications. It allows creation and configuration of enterprise-specific custom transports using the Custom Transport Software Development Kit (SDK) and native transport for AquaLogic Data Services platform. It provides the ability to create a generic proxy services that can accept any SOAP or XML message, using generic proxy service templates.

AquaLogic Service Bus supports optimized database queries across the SOA for high performance and reliability, and interoperability with web service integration technologies including .NET, Tibco EMS, IBM MQ, IBM WebSphere, Apache Axis, Cyclone B2B Interchange, and iWay adapters.

For information on AquaLogic Service Bus interoperability, see AquaLogic Service Bus Product Support Information and AquaLogic Service Bus Interoperability and Transports documentation.

Optimized Pluggable Security Layer

BEA AquaLogic Service Bus ensures service security at all levels. A comprehensive set of components for built-in security give customers significant flexibility and choice. Users can also plug in home-grown or third-party security components. Built-in capabilities allow flexibility in implementation by enabling security at the following levels:

For more information on AquaLogic Service Bus security features, see AquaLogic Service Bus Security Guide.

For more information on AquaLogic Service Bus supported standards, see Supported Standards and Security Providers in AquaLogic Service Bus Security Model.

Rich Service Composition Layer

BEA AquaLogic Service Bus provides a rich environment for service configuration, modeling, discovery and message validation. It also supports message transformations, service callouts to external service providers, and a test browser.

Figure 1-13 Service Composition Layer

Service Composition Layer

BEA AquaLogic Service Bus configuration-driven composition environment, with WorkSpace Studio and the ALSB console, is designed with a no coding approach, allows message flow modeling using versatile graphical modeling tools. The modeling capabilities allow for configuration of dynamic content-based routing, message validation and exception handling. For more information on dynamic routing, see Service Composition , topic Dynamic Content-Based Routing.

The composition environment includes a service discovery and validation capabilities for automatic import and synchronization of services with UDDI registries. This functionality allows for validation to ensure service integrity and reconciliation of conflicts before deployment. For more information on UDDI registries, see Service Configuration, topic UDDI Registry.

BEA AquaLogic Service Bus supports XML and non-XML transformation of disparate data types shared between source and destination services. Data mappings using XQuery and the eXtensible Stylesheet Language Transformation (XSLT) standard are supported. These can be created externally and imported into BEA AquaLogic Service Bus, or scripted using XQuery in the BEA AquaLogic Service Bus Console. Message content reformatting can be performed using XQuery or XSLT or by manipulating message content by adding, removing, or replacing selected elements. For more information on transformations, see Service Composition, topic Transformations..

BEA AquaLogic Service Bus supports dynamic routing through a service callout feature which allows more flexible and sophisticated message flow modeling. Service callouts within message flows can be used to invoke other services registered within BEA AquaLogic Service Bus and may be Java exit (Plain Old Java Object) or Web Services call-outs. The composition environment also features a test console for tracing and trouble-shooting services. For more information on service callouts, see Constructing Service Callouts in BEA AquaLogic Service Bus User Guide.

Embedded Service Management Layer

BEA AquaLogic Service Bus offers embedded service management capabilities that provide optimized governance of all messaging. Its preemptive support ensures that mission-critical business processes continue to serve customer needs, even as business demands, requirements, and workloads change.

Figure 1-14 AquaLogic Service Bus Embedded Service Management

AquaLogic Service Bus Embedded Service Management

AquaLogic Service Bus Dashboard provides an unified data service interface for all application development and maintenance, service monitoring and management and improved operations support. The dashboard allows for monitoring of fault and performance metrics, viewing of summaries for aggregated ESB. It allows for dynamically defining and managing routing relationships, transformations, and policies. For more information on Dashboards, see Service Management, topic Dashboard.

AquaLogic Service Bus has built-in optimizations for performance and monitoring, guarantee quality of service through alert monitoring on single node or entire server, and configurable Service Level Agreements (SLAs) for messages. It also supports viewing and managing SLA alerts on operation metrics and message pipelines. For more information on configuring SLAs, see Service Management, topic SLA Enforcement via Alerts.

AquaLogic Service Bus allows integration of widely adopted out-of-the-box third-party reporting tools as well as custom Enterprise Systems Management frameworks. In addition, it supports open interfaces for operational and deployment customization, JMX monitoring interfaces and SNMP Alerts. For more information on reporting features, see Service Management, topic Message Reporting.

Feature Benefits

The following table summarizes functional features of the BEA AquaLogic Service Bus and highlights the business requirements addressed by each functionality.

Table 1-1 AquaLogic Service Bus Features and Benefits

Functionality
Functional Feature
Business Benefit
Message Routing
Configuration-driven intelligent, content-based and identity-based routing
Rapidly respond to business needs by quickly configuring routing rules based on changes to business rules or existing IT systems, without coding
Message Transformation
Dynamic message transformation based on XQuery or XSLT, supporting multiple message formats
Flexibly adapt to evolving SOA and integration project scenarios through the ability to dynamically transform and route services using simple and/or complex routing rules and/or message payloads
Service Registry
Automated or administrator-driven interoperability with UDDI V3 registries for service publishing and reuse
Increase ease of re-use by automatically discovering existing services and exporting new services to the service registry
Service Provisioning
Simplified service provisioning
Increase ease of managing multiple versions of services, simplify and speed deployments by eliminating build-test development cycles
Message Security
Optimized, pluggable, policy-driven transport and message level security
Leverage existing investments in security infrastructure and seamlessly broker between multiple security frameworks
Service End-point Interoperability
Extensibility and expanded service end-point support
Extend solution to accommodate unique IT requirements using infrastructure with certified interoperability with multiple standards, protocols, and vendors
Service Level Agreements
Rules-driven, configurable Service Level Agreement (SLA) enforcement
Gain visibility and control by enabling users to set SLAs based on a number of factors and alerts when the SLAs are not met
Message Transport
Extensible support for heterogeneous transports between service end points including custom transports via the Custom Transport SDK
Provides flexibility to leverage existing investments in disparate systems and/or ensure smooth transition from older to newer systems
Message Brokering
WS-I compliant Intelligent messaging brokering with support for multiple transport types, message formats
Ensure investment protection and leverage existing infrastructure through the ability to orchestrate services from existing IT systems with disparate messaging protocols without needing to change the systems and styles
Service Availability
Proactive infrastructure health and availability monitoring with JMX and SNMP
Maintain health and availability of the SOA through easy configuration of support of performance metrics and SLAs using a built-in, feature-rich dashboard OR 3rd party performance management systems.
Service Monitoring Dashboard
Flexible, graphical, and embedded management and monitoring dashboard
Automatically monitor and manage status of performance metrics and SLAs using a built-in, feature-rich dashboard or 3rd party performance management systems. Proactively take corrective action based on alerts.
Service Deployment
Easy, customizable programmatic or console-driven deployment
Ability to enforce governance and speed deployments

Related Topics


  Back to Top       Previous  Next