An empirical study of messaging systems and migration to service-oriented architecture
Raouf Alomainy and Wei Li Computer Science Department, University of
Alabama in Huntsville, Huntsville, AL 35899 {ralomain, wli}@cs.uah.edu Abstract
In a heterogeneous network, messaging systems facilitate the exchange of essential information among different system modules. This paper investigates the use of traditional messaging system in conjunction with the service-oriented architecture (SOA) principles to extend the system with minimum refactoring and redesign. The paper investigates in particular the Oracle Advanced Queuing (AQ), a basic component of Enterprise Oracle database software and the use of web services to make the solution SOA-enabled that offers a cost effective solution for an integration framework that provides database features (e.g. persistence and scalability) that are independent of web-service platforms.
Keywords: database messaging, integrations, web services, service oriented architecture.
Introduction
Messaging systems are becoming increasingly important in today’s computing due to the rise in demand of integration software modules that facilitate the exchange of essential information among different systems in a heterogeneous network [Lewis 1999]. One main area of
messaging framework is database system queues and the exchange of synchronous and
asynchronous messages. However, the rise of web services and SOA-based architectures is making integration solutions based on traditional messaging technologies increasingly unpopular, thus the need to have an efficient migration strategy from traditional systems to SOA-based messaging is even more critical for large corporations that depend heavily on integration solutions for their business.
Our approach shows that the SOA extension of AQ database messaging system preserves scalability and performance features of the system. Moreover, the SOA extension using web services enables the integration to be open and platform independent architecture that is interoperable with external applications in a heterogeneous network that would have not been possible before without costly and time
consuming redesign that could require additional middleware and integration bridge
implementations. The paper also presents a practical commercial product that utilizes the techniques introduced as part of this work with some preliminarily results that shows the effectiveness of the migration solution for SOA enablement.
Enterprise applications involve distributed processing and cross-site communication that rely on middleware. Traditional database messaging systems, such as IBM MQSeries and Oracle Advanced Queuing (AQ) [Feuerstein et al 1998] [Lewis 1999], seeks to integrate
messaging operations into database to provide a single Application Programming Interface (API) for data processing and messaging, and to make client applications easier to write, since all the logic of sending
and receiving messages is within one database. System configuration, application deployment, and message maintenance become flexible because there is no need to maintain and tune multiple and loosely coupled products. In recent years, SOA architecture has been gaining momentum within the integration and web-service communities. SOA provides methods for system development and integration where systems package functionality as
interoperable services. Service-orientation strives to provide a loose coupling of services with operating systems, programming languages, and other software technologies that underline applications. SOA separates functions into distinct units, or services, which developers make accessible over a network so that users can combine and reuse them in the production of applications. These services interface with each other by exchanging data from one service to another [Barry 2003] [Zhao 2006] [Dan et al 2006].
This paper investigates the SOA enablement of integration solutions that are based on AQ. We will also show how to build SOA-based web services using AQ by using an integration strategy that extends AQ and builds SOA-based Services as front end for message exchange. We present a recent industry case study that was conducted using the migration strategy described in this paper.
Extension of messaging systems to SOA When applications communicate with one other, producer applications enqueue messages and consumer applications dequeue messages. AQ provides database-integrated message queuing and leverages the functions of the Oracle database so that messages can be stored persistently and propagated among queues on different machines and databases easily. [Feuerstein et al 1998]. Since AQ is implemented in database tables, all the operational benefits of high availability, scalability, and reliability are applicable to queued data. Standard database features such as recovery, restart, and security are supported for queued data as well, and queue tables can be imported and exported easily.
Proposed SOA
We will present in this section on how AQ can be used to complement SOA in integration solutions without affecting any of the key features of SOA [Barry 2003] [Dan et al 2006]. SOA services could be implemented in
Enterprise Service Bus (ESB)-based systems. SOA-based integrations offer these key features: consistency, interoperability with different ESB vendors, loosely coupled architecture, clear separation between business layer and messaging layer, and extensible integration with reduced cost and time [Barry 2003][Hohpe and Woolf 2003].
Enabling the messaging framework of any integration via SOA product require the following:
• Remove the dependency on specific messaging systems, such as Oracle Advanced Queuing as the main internal messaging system.
• Define a messaging layer that provide a well-defined interface to allow the encapsulation of messaging specific details and provide the flexibility to choose between different transport technologies (AQ, ESP-AquaLogic, ESP-WebSphere, etc)
• Provide a framework to provide “manager” hooks to tie the business services with appropriate messaging SOA services.
SOA-based messaging architecture There are several methodologies to implement SOA services. There were two possible architecture scenarios that were experimented as part of our work to SOA-enable an integration solution.
Web Services is the most widely accepted technology for implementing SOA today. Use of Web Services specifications require
implementation that exchange messages of the type Simple Object Access Protocol (SOAP) envelope. Also, SOA Web Services could utilize the two main standards for message
communications, the Web Services Description Language (WSDL) and XML Schema Definition
(XSD). In addition, this allows to leverage other WS standards and capabilities to support existing and emerging * standards such as WS-Security and WS-ReliableMessaging in the SOA implementation of the Web Applications. Strategy 1: SOA-Enabling via Web services adapter
This approach eliminates the dependency on a specific messaging technology, such as Oracle AQ as the backend messaging systems and instead relies on industry-based Enterprise System Bus (ESB) systems for messaging. In addition, these systems usually offer other third-party tools that would not be available if in-house messaging is used, such as
mapping/transformation tools, Service registry tools, artifacts building toolset and others.
Figure 1: SOA Framework via WS adapter
There are several advantages to this approach:
• Eliminates the dependency on specific database as the backend messaging system.
• This allow for the usage for different messaging systems directly without any middle layers. These are systems other than ESBs, such as MQSeries,
SoniqMQ, others.
• No need for double bus architecture as the central ESB is the only messaging system being employed.
• Provides the advantage of using numerous useful tools available with the ESB. For example for mapping, transformation, service registry, etc. However, there are also disadvantages to this approach:
• If no ESB is employed for messaging, there is no guarantee for Quality of Services (QoS) for reliability and fault-tolerance. Usage of the internal AQ queues would provide these advantages.
• This makes the integration solution more costly since these ESB are expensive and require additional resource/time to implement, configure and maintain.
• Different ESBs require different implementation strategies.
Strategy 2: SOA-Enabling via Oracle AQ With the second alternative, the basic messaging system of Oracle Advanced queuing (AQ) is used as a backend queuing that serves to persist messages and ensure fault tolerance, whereas communication between internal AQ queues with SOA Web services is being handled via basic message routers. Figure 2 : SOA
Framework via AQ depicts this architecture. In this architecture fault-tolerance and reliability of messages being exchanged are being provided via AQ, which would be useful when no central ESB is employed in the solution.
Figure 2 : SOA Framework via AQ There are several advantages to this approach:
• Fault-tolerance and reliability is guaranteed, in particular in solutions where there is no central ESB (Enterprise Service Bus) system.
• Reusability of existent Oracle AQ adapters and only expose their services as SOA Web Services.
• Besides fault tolerance ease of confiyration, we can utilize the asynchronous aspect of AQ and allow for multiple message consumers to allow for a more load balanced system and parallelism
• Less costly since it does not require third-part ESB systems.
However, there are also disadvantages to this approach:
• Dependency on Oracle AQ as the backend queuing system.
• The introduction of middle layer (Message Routers) to communicate the messages between the internal AQ queues and Web Services.
After we presented the two integration strategies for SOA enablement and migration from traditional messaging systems, we chose, for our experimental SOA enablement, the second strategy that depends on an architecture
extension to provide SOA web services, but still utilizes AQ as the main messaging system without much change and disturbance to existent architecture, because this approach provides more cost effective and scalable solutions that adopts to SOA principles.
An empirical study
This approach is currently being employed to implement a commercial telecommunication integration product that was previously built using AQ messaging systems only and underwent a transition project to adapt SOA architecture using the proposed architecture in Figure 2 - Strategy 2: SOA-Enabling via Oracle AQ. The SOA enablement environment consists of these components:
• Microsoft Internet Information Services (IIS): to implement the SOA web services that exposes and provide specific business functions. IIS could be substituted for any third party ESB systems as per the organization needs. There are several common Enterprise Service Bus (ESB) systems to host the SOA services, BEA AquaLogic, IBM WebSphere, or TIBCO, which are more expensive and provides additional tools and applications to support web services build out.
• Oracle Advanced Queuing: The AQ instance where the queues are established for messaging
• SOA-AQ Message dispatcher: This will act as the bridge between the AQ queues component and the IIS based SOA services.
Figure 3: A practical SOA extension of AQ based Integration solution using Microsoft IIS
Conclusions and future research We have demonstrated that the combination of Oracle AQ with SOA offers a cost effective solution for an integration framework that provides database features (e.g. persistence and scalability) with platform independence for web services. Our approach offers a migration strategy that does not incur costly refactoring and redesign and lesser risk associated with changes to an enterprise infrastructure. The migration strategy offers a solution towards the SOA enablement without incurring additional resources and budget constraints that make such migration projects expensive and less desirable, in particular for medium-size corporations. As the empirical study showed, our approach not only preserved the original advantages that came from using database messaging systems, but also complemented the system and enabled it for SOA implementation for the latest web-service architecture and allowed both direct messaging integration as well as SOA based web-service integration.
In the future, we will explore extending the system to decouple the backend messaging system from AQ to utilize different database messaging systems such as MQSeries [Lewis 1999].
References
[Barry 2003] Barry, Douglas K.: Web services and service-oriented architectures: the savvy manager's guide. 2003
[Feuerstein et al 1998] Steven Feuerstein, Charles Dye & John Beresniewicz. Oracle Built-In Packages. First Edition, published 1998-04-01.
[Hohpe and Woolf 2003]Gregor Hohpe, Bobby Woolf.: Enterprise integration patterns : designing, building, and deploying messaging solutions. October 2003
[Shi and Murthy 2003] Nan Si Shi, V.K. Murthy.: Architectural issues of Web-enabled electronic business. 2003
[Lewis 1999] Rhys Lewis. Advanced Messaging Applications with MSMQ and MQSeries. 1999 [Zhao 2006] Yan Zhao.: Enterprise Service Oriented Architecture (ESOA) Adoption Reference. 2006. SCC '06. IEEE International Conference on Services Computing. 18-22 Sept. 2006 Page(s):512 – 512. 2006
[Dan et al 2006] Xie Dan; Ying Shi; Zhang Tao; Jia Xiang-Yang; Liang Zao-Qing; Yao Jun-Feng. : An Approach for Describing SOA. Wireless Communications, Networking and Mobile Computing, 2006. WiCOM 2006.International Conference. 22-24 Sept. 2006 Page(s):1 – 4. September 2006.
[Kumari et al 2008] Kumari, G.P.; Kandan, B.; Mishra, A.K.: Experience Sharing on SOA Based Heterogeneous Systems Integration. Congress on Services - Part I, 2008. SERVICES '08. IEEE 6-11 July 2008 Page(s):107 – 108. July 2008. [Komoda 2006] Komoda, N.: Service Oriented Architecture (SOA) in Industrial Systems. IEEE International Conference on Industrial
