Building ESB Product Lines

Indika Kumara Chandana Gamage

Building ESB Product Lines

Building ESB Product Lines

Indika Kumara MSc (Moratuwa), BSc Eng (Hons) (Moratuwa) WSO2, Colombo, Sri Lanka

Chandana Gamage PhD (Monash), MEng (AIT), BSc Eng (Hons) (Moratuwa) University of Moratuwa, Moratuwa, Sri Lanka

2010

c Copyright 2010 by Indika Kumara and Chandana Gamage

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system of any nature, or transmitted in any form or by any means, electronic, mechanical, now known or hereafter invented, including photocopying or recording, without prior written permission of the publisher. Published by the authors. ISBN 978-955-51681-0-3

Printed in Sri Lanka

Contents

1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Enterprise Service Bus (ESB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Variability in ESB Products . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Commonality in ESB Products . . . . . . . . . . . . . . . . . . . . . . 1.2 An Approach for Dominating the ESB Market . . . . . . . . . . . . . . 1.2.1 Multiple Product Lines of an ESB . . . . . . . . . . . . . . . . . . . 1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 2 4 4 6 7

2

The Enterprise Software Ecosystems . . . . . . . . . . . . . . . . . . . . . . . 2.1 Related Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Enterprise Service Bus (ESB) . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Aspect Oriented Programming (AOP) . . . . . . . . . . . . . . . 2.1.3 Domain Specific Language (DSL) . . . . . . . . . . . . . . . . . . . . 2.1.4 Adaptive Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5 Software Product Line (SPL) . . . . . . . . . . . . . . . . . . . . . . . 2.2 Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Logging Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Security Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Caching Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Exception Handling Aspect . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Validation Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.6 Persistence Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.7 Transaction Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.8 Fault Tolerance Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.9 Monitoring Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.10 Load Balance Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 AOP System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Proxy Factory Based Architecture . . . . . . . . . . . . . . . . . . . 2.3.2 Policy Injection Application Block Architecture . . . . . . . 2.3.3 Composition Filters Model . . . . . . . . . . . . . . . . . . . . . . . . .

9 9 9 13 18 19 20 21 21 23 24 26 28 29 30 31 31 33 35 35 36 37

VI

3

Contents

2.3.4 An AO Framework in OOP Environment . . . . . . . . . . . . . 2.4 Aspect Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Need for Aspect Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Aspect Mining Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Feature Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Aspect Mining and Refactoring . . . . . . . . . . . . . . . . . . . . . 2.5 AOP Based Software Product Line . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Research on AOP and ESB . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.2 AOP Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3 Component Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.4 Multiple Product Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38 39 39 39 40 40 42 43 43 44 45 46 46

An Aspect-Oriented Platform for Multiple ESB Product Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Applying Aspect Oriented Programming . . . . . . . . . . . . . . . . . . . 3.2 Multi-Architectures Reusable Asset . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Design and Implementation Strategies . . . . . . . . . . . . . . . 3.3 Aspect Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Log Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Error Handling Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Persistence Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 Cache Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.6 Monitoring Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.7 Load Balance Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.8 Crypto Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.9 Proxy Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Aspect Weaver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Aspect Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Aspect Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Aspect Weaving Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Aspect and Composition Definition Language . . . . . . . . . . . . . . . 3.5.1 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 BNF Grammar for ACDL . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Using ACDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.4 Implementation of ACDL . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Integration Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49 50 50 51 51 55 55 56 58 60 61 63 65 67 67 68 68 68 71 74 75 75 75 75 78 80 80

Contents

VII

4

A Design for Multiple ESB Product Lines . . . . . . . . . . . . . . . . . 83 4.1 Realizing Multiple ESB Product Lines . . . . . . . . . . . . . . . . . . . . . 83 4.1.1 A Model of Multiple ESB Product Lines . . . . . . . . . . . . . 83 4.1.2 Creating Each ESB Variation . . . . . . . . . . . . . . . . . . . . . . . 84 4.1.3 Creating Individualized ESBs . . . . . . . . . . . . . . . . . . . . . . . 85 4.1.4 Selecting the Features of an ESB Service . . . . . . . . . . . . . 85 4.2 The Evaluation of the Product Line Platform . . . . . . . . . . . . . . . 87 4.2.1 Quantitative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.2.2 Qualitative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.3 Further Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

A

Case Study Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.1 Scenarios 1 - 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.1.1 The Synapse Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.1.2 The ACDL for Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.1.3 The ACDL for Scenario 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 109 A.1.4 The ACDL for Scenario 7 . . . . . . . . . . . . . . . . . . . . . . . . . . 109 A.1.5 The ACDL for Scenario 9 . . . . . . . . . . . . . . . . . . . . . . . . . . 110 A.1.6 The ACDL for Scenario 11 . . . . . . . . . . . . . . . . . . . . . . . . . 110 A.2 Scenarios 13 and 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 A.2.1 The Synapse Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.2.2 The ACDL for Scenario 13 . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.3 Scenarios 14 and 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.3.1 The Synapse Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 114 A.3.2 The ACDL for Scenario 14 . . . . . . . . . . . . . . . . . . . . . . . . . 114 A.4 Scenarios 17 - 22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 A.4.1 The Synapse Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 116 A.4.2 The ACDL for Scenario 17 . . . . . . . . . . . . . . . . . . . . . . . . . 116 A.4.3 The ACDL for Scenario 18 . . . . . . . . . . . . . . . . . . . . . . . . . 117 A.4.4 The ACDL for Scenario 20 . . . . . . . . . . . . . . . . . . . . . . . . . 117 A.4.5 The ACDL for Scenario 22 . . . . . . . . . . . . . . . . . . . . . . . . . 120

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

List of Figures

1.1 1.2

Feature Model Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Feature Model for ESB Product Lines . . . . . . . . . . . . . . . . . . . .

5 5

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22

A Generic ESB Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Crosscutting Phenomenon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aspects, Advices, Point-cuts and Joint Points . . . . . . . . . . . . . . . . Static Weaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic Weaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Projection of DSL into UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Design of the Logging Application Block . . . . . . . . . . . . . . . . . . A Design of the Security Application Block . . . . . . . . . . . . . . . . . . A Design of the Cryptography Application Block . . . . . . . . . . . . . A Design of the Caching Application Block . . . . . . . . . . . . . . . . . . A Design of the Exception Handling Application Block . . . . . . . . A Design of the Validation Application Block . . . . . . . . . . . . . . . . A Design of the Data Access Application Block . . . . . . . . . . . . . . QoS Observer Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A SLA Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scaling by Distributing Load across Multiple Service Instances . The Proxy Factory Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handler Pipelines of the Policy Injection Application Block . . . . The Basic Structure of the Composition Filters Model . . . . . . . . An AO Framework in OOP Environment . . . . . . . . . . . . . . . . . . . . An Approach for Analyzing Legacy Systems . . . . . . . . . . . . . . . . . An Aspect-Oriented Product Line Framework . . . . . . . . . . . . . . . .

11 15 16 17 18 19 23 24 25 27 28 29 30 32 32 35 36 36 37 38 42 44

3.1 3.2 3.3 3.4 3.5

Message Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interceptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Design of the Log Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Design of the Exception Handling Aspect . . . . . . . . . . . . . . . The Design of the Persistence Aspect . . . . . . . . . . . . . . . . . . . . . . .

52 53 56 59 60

X

List of Figures

3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23

The Design of the Cache Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Design of the Monitoring Aspect . . . . . . . . . . . . . . . . . . . . . . . The Design of the Load Balance Aspect . . . . . . . . . . . . . . . . . . . . . The Design of the Crypto Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . Secure Logger Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synapse Skeleton Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Skeleton Component Configuration for the Secure Logger . . Synapse Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AspectObjectModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Aspect Composition for the Motivating Example . . . . . . . . . ObjectModelDecorator Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . The BNF Grammar for the ACDL . . . . . . . . . . . . . . . . . . . . . . . . . . An ACDL Example Defining Aspects . . . . . . . . . . . . . . . . . . . . . . . An ACDL Example Defining Aspect Composition . . . . . . . . . . . . An Aspect Composition Example in Detail . . . . . . . . . . . . . . . . . . The ACDL Token Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The ACDL Configuration Building . . . . . . . . . . . . . . . . . . . . . . . . .

62 64 65 67 68 70 70 71 72 73 74 74 76 77 77 78 78 79

4.1 4.2 4.3 4.4 4.5

A Feature Model for Multiple ESB Product Lines . . . . . . . . . . . . The Feature Model of the Log Aspect . . . . . . . . . . . . . . . . . . . . . . . The Feature Model of the Cache Aspect . . . . . . . . . . . . . . . . . . . . . The Feature Model of the Load Balance Aspect . . . . . . . . . . . . . . The Overhead of the Aspect Adaptation . . . . . . . . . . . . . . . . . . . .

84 86 87 87 89

A.1 The A.2 The A.3 The A.4 The A.5 The A.6 The A.7 The A.8 The A.9 The A.10 The A.11 The A.12 The A.13 The A.14 The A.15 The A.16 The A.17 The A.18 The A.19 The A.20 The

Synapse Configuration for Scenarios 1-12 . . . . . . . . . . . . . . . . 108 ACDL for Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Aspect Weaving for Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . 109 ACDL for Scenario 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Aspect Weaving for Scenario 4 . . . . . . . . . . . . . . . . . . . . . . . . . 111 ACDL for Scenario 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 ACDL for Scenario 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 ACDL for Scenario 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Aspect Weaving for Scenario 11 . . . . . . . . . . . . . . . . . . . . . . . . 113 Synapse Configuration for Scenarios 13 and 15 . . . . . . . . . . . 114 ACDL for Scenario 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Synapse Configuration for Scenarios 14 and 16 . . . . . . . . . . . 115 ACDL for Scenario 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Aspect Weaving for Scenario 14 . . . . . . . . . . . . . . . . . . . . . . . . 117 Synapse Configuration for Scenarios 17 - 22 . . . . . . . . . . . . . . 118 ACDL for Scenario 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Aspect Weaving for Scenario 17 . . . . . . . . . . . . . . . . . . . . . . . . 119 ACDL for Scenario 18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 ACDL for Scenario 20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 ACDL for Scenario 22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

List of Tables

1.1

The Commonality in ESB Products . . . . . . . . . . . . . . . . . . . . . . . . .

3

4.1

The Overhead of the Aspect Adaptation . . . . . . . . . . . . . . . . . . . . 88

Preface

Nowadays, enterprises are utilizing Enterprise Application Integration (EAI) technologies to automate their business processes and the Enterprise Service Bus (ESB) is the current state of art of the EAI technologies. ESB products are heterogeneous, mostly in terms of architectures, and features. Each product variation has a separate customer base, which is attributed to the features and architecture of the product. The customer base of an ESB is heterogeneous and consists of domains such as e-commerce, healthcare, and government. It can also be classified based on the business scale such as large, medium, and small. We believe each customer prefers an ESB product that can solve his or her application integration problems in a scalable and robust manner. Therefore, the selection of an ESB product for an enterprise is attributed to the business domain and business scale of an enterprise. Our analysis of the ESB sphere led us to recognize that the ESB market can be dominated with a capability to develop each ESB variation and to offer individualized ESB products, which are customized to support the requirements of a particular customer base efficiently. We believe that software product line is a suitable approach for providing such a capability. Software product line (SPL) is a family of products, derived from a common platform. Traditional SPL approaches usually develop products with the same architecture and provide a systematic reuse only within a single product family. Therefore, for an organization, the suitable approach to develop different software systems would be multiple product lines. A platform for multiple product lines should provide a systematic reuse within multiple product families and be capable of producing products with different architectures. In this book, we discuss an attempt to develop a platform to support the development of the multiple product lines of an ESB. The foundation of our approach is the development of architecture independent generic components and transparent transformation of a single generic component into the components of different architectures. We adopted AOP (Aspect-Oriented Programming) to modularize the commonalities across ESB products. The

XIV

Preface

commonalty is mainly ESB services such as routing, transform, security, and monitoring, whereas the variability encompasses architectures and features. We capture the ESB services as aspects, and provide a methodology to design and implement those in a way that the quality attributes expected by different products can be provided. We discuss a technique for effectively adapting a generic component (an aspect) into a component of a particular architecture. We present a novel aspect weaving approach to structure the aspects based on the architecture styles that are suitable for the products, which are going to use the aspects. We present an aspect library, which consists of eight aspects, and a language to define both the aspects and their compositions. Moreover, we discuss a design for multiple ESB product lines and provide an experimental evaluation, which shows our platform can support the development of ESB product lines. Organization of the Book Chapter 1 introduces an ESB, and outlines the opportunities for the multiple product lines of an ESB. We discuss how multiple product lines can provide an adequate capability to dominate the ESB market. We also present the contributions of our research of a platform for the multiple ESB product lines. Chapter 2 is dedicated to provide a comprehensive analysis of research literature related to this research. First, it describes the related technologies including ESB, AOP, SPL, and DSL. Thereafter, it explores a set of common aspects related to an ESB, AOP framework architectures, and AOP-based SPL approaches. Finally, it discusses previous research attempts in detail followed by a conclusion about the foundation provided by the research literature for this research project. The proposed platform is discussed in chapter 3. It consists of four main sub sections: Aspect Weaver, Aspect Library, Aspect Definition and Composition Language (ACDL), and Integration Layer. Each sub-section describes the design and implementation of the corresponding software component in detail. It also consists of a discussion about the design decisions and their consequences. In additions to the platform, an aspect development technique and an aspect adaptation technique are presented. Chapter 4 presents a design of multiple ESB product lines and explores the products line opportunities created by this research. Furthermore, it analyzes the platform. We broadly divide our analysis into two major categories: quantitative and qualitative. The quantitative analysis includes a case study, which uses our platform in a real world ESB. The qualitative analysis presents a goal-oriented analysis and a software quality attributes analysis of the platform. Finally, chapter 5 summarizes and concludes the key research outcomes and findings, discusses the limitations of the research work, and ends with directions for future work.

Preface

XV

Acknowledgements This book is an outcome of a research project conducted at the Department of Computer Science and Engineering of the University of Moratuwa in Sri Lanka and WSO2 in Colombo, Sri Lanka. University of Moratuwa is the top rated engineering university in Sri Lanka and WSO2 is a leading open source Service Oriented Architecture (SOA) solutions provider with major contributions in SOA technology with its R&D facilities located in Colombo. Our work has been supported by many friends and colleagues including Dr. Sanath Jayasena, Dr Shehan Perera and the academic staff at Dept of CSE, Dr. Sanjiva Weerawarana, Mr. Ruwan Linton, Mr. Asankha Perera, and the WSO2 ESB team. Finally yet importantly, we want to gratefully acknowledge the support and encouragement of our families.

July 2010

Indika Kumara Chandana Gamage

1 Introduction

I found out that if you are going to win games, you had better be ready to adapt. – Scotty Bowman Empty your mind, be formless, shapeless - like water. Now you put water into a cup, it becomes the cup, you put water into a bottle, it becomes the bottle, you put it in a teapot, it becomes the teapot. Now water can flow or it can crash. Be water, my friend. – Bruce Lee An Enterprise Service Bus (ESB) is a leading middleware infrastructure that provides Enterprise Application Integration (EAI). The ESB market has been growing in terms of different ESB products, vendors, and customers. We believe that a single ESB vendor can dominate the ESB market with a capability to develop each product variation that competitors develop, and to offer the products that are customized for providing efficient and robust integration solutions for a particular customer base. In this chapter, we briefly introduce the ESB and present an analysis of the commonalty and variability among ESB products. We also outline our approach to enable single ESB vendor to dominate the ESB market.

1.1 Enterprise Service Bus (ESB) In modern business environments, Information Technology (IT) has become a key success factor. It can assist an enterprise by automating the business processes and simplifying the operational activities. Typically, a business process is realized by integrating the enterprise computer applications, which provide a particular set of business functions. For the past decades, enterprises have adopted Enterprise Application Integration (EAI) technologies to enable integration of applications across enterprises.

2

1 Introduction

Enterprise Service Bus (ESB) is the descendant of the race of EAI solutions and is capable of solving a broader range of integration problems comparing to its predecessors [1]. The dominant service of an ESB is the interoperability, which enables loose coupling between service consumers and providers. An ESB also provides services such as caching, security, monitoring, etc. An ESB has multiple definitions and many of them are conflicting. We adhere to the definition provided by Rosen, Lublinsky, Smith, and Balcer [2]. An ESB is an enterprise-wide extendable middleware infrastructure providing virtualization and management of service interactions, including support for the communication, mediation, transformation, and integration technologies required by services. By serving as a communication intermediary, an ESB lowers the coupling between service consumers and providers through providing virtualization and management of the interactions between service consumers and providers. 1.1.1 Variability in ESB Products ESB products are available from a wide variety of vendors, and these products differ on many aspects such as architecture, base technologies, and features [3]. As the architecture of a software system usually determines the software qualities offered by the software system, we have focused only on the ESB architecture variation. ESB architectures can be broadly categorized into four: JBI, SCA, MQM, and ad-hoc. The foundation of JBI is a central mediator providing the loose coupling between the JBI components. Using a message-based service invocation described using a standard service description language, the JBI components communicate with each other. Ten-Hove and Walker [4] describe JBI in detail in the JBI specification. ServiceMix and Mule belong to this category [3]. SCA defines how to create SCA components and assemble them to implement business processes. The decoupling of the business logic from the access methods provides flexibility to use different communication mechanisms to collaborate between components. Chappell [5] introduces SCA including its fundamental concepts and the approaches of realizing it. WebSphere ESB is based on SCA. In MQM, applications communicate by inserting messages in specific queues. The applications can be physically distributed. These systems provide extensive support for reliable, asynchronous, and loosely coupled communication. Sonic ESB is an example for this category [3]. 1.1.2 Commonality in ESB Products The identification of the commonality in appropriate granularity is crucial as it determines the level of reuse and the cost associated with the product

1.1 Enterprise Service Bus (ESB)

3

development from reusable assets. The primary concerns to be considered are the level of abstraction, coupling and functional orthogonality. Our approach to identify the commonality is to consider each ESB product as a black box and examine the externally visible features or services they provide. We selected three ESB products: Mule, Synapse, and Fiorano ESB. Synapse [6] is an open source ESB and has an architecture that assembles its components in a sequence. Mule ESB is JBI based and the architecture of Fiorano ESB is based on MQM [3]. Table 1.1 summarizes ESB services, which each ESB provides, and we have only considered six services as the selected services cover the essentials required to identify the commonality in ESBs. Table 1.1. The Commonality in ESB Products ESB Services Mule

ESB Products Synapse

Fiorano

Routing

Content and Header Based CBR Routing (CBR and HBR) HBR

and CBR HBR

and

Transform

XML(Extensible XML Markup Language) and EDI(Electronic Data Interchange)

Transport Services

HTTP / HTTPS, FTP, HTTP/S,FTP,HTTP/S,FTP, JMS(Java Message Service), Email, JMS, Email, JMS, Email, Amazon SQS (Sim- etc etc ple Queue Service), etc

Security

LDAP (Lightweight Direc- WS-Security tory Access Protocol), WSSecurity, JAAS(Java Authentication and Authorization Service)

XML and EDI

WS-Security, LDAP,JAAS

Load Balance -

support

support

Caching

In-memory Caching

In-memory Caching

-

As shown in Table 1.1, each ESB provides transformation and routing and there are services such as load balance, and caching that are provided by more than one ESB. Every ESB provides HTTP, JMS, FTP, and Email transport services. However, there are transport services such as Amazon SQS, etc., that are provided by only a single ESB. Apparently, Each ESB provides a sub set of transport services. From our analysis, it is evident that each ESB provides a sub set of ESB services and a sub set of the functionality of a particular ESB service. This conclusion can also be traced from the data transformation and security services provided by each ESB. Therefore, each existing ESB can

4

1 Introduction

be viewed as a software system that is using a subset of ESB services from a universal ESB service library with different service composition architectures such as JBI, MQM, etc. This fact motivated us to recognize the ESB service abstraction as the unit of reuse.

1.2 An Approach for Dominating the ESB Market As per the discussion in Sect. 1.1, the ESB products represent a set of architectures. The difference in the architectures makes each product differ in terms of quality attributes such as performance, reliability, and extensibility. Prior research has evaluated the existing ESB products and their architectures [3, 7] and evidently, the architecture drives the selection of an ESB for a particular enterprise. The customer base of an ESB is also heterogeneous and consists with domains such as e-commerce, healthcare, and government. It can also be broadly classified based on the business scale such as large, medium, and small. Each customer wants an ESB that can solve his or her integration problems efficiently. Therefore, the selection of an ESB product for an enterprise also is attributed to the business domain and the business scale of an enterprise. The diversity in the ESB products and the customer base emphasize the reality that a one-size-fits-all ESB product strategy will not be successful. This is applicable to both customers and vendors and flexibility and adaptability should be seen as key features. The vendors should have a flexibility to produce what the customers want while the customers should have a flexibility to select an ESB as well as to adapt the selected ESB to support the changing business requirements. How can a single ESB vendor exploit the heterogeneity in the ESB products as well as the heterogeneity in the ESB customer base so that both the customers and the vendor can benefit? A suitable solution is a family of products; each customized to a particular customer base or presenting a specific ESB variation. How can a single vendor formulate such a family of products? A potentially viable approach is ESB product lines, which is a set of ESB products where each ESB is tailored to the specific attributes such as the dominant message protocol, dominant ESB services of a particular application domain. For example, an ESB for the mission-critical and high volume applications require a higher reliability and availability. This has led most enterprises in those domains to adopt MQM based ESBs. 1.2.1 Multiple Product Lines of an ESB The traditional way to build a software product line (SPL) is the explicit, planned reuse of a common architecture and elements that populate it, across multiple similar systems [8]. For an organization, the suitable approach to

1.2 An Approach for Dominating the ESB Market

5

develop different software systems would be multiple product lines. Therefore, our approach for dominating the ESB market is multiple product lines of an ESB. We attempted to develop a platform for ESB multiple product lines. SPL has succeeded due to the large-grained reuse within a single product family. Thus, multiple product lines should provide a systematic reuse within multiple product families [9]. Therefore, a platform for multiple product lines should enable a large-scale reuse among multiple product families and be capable of producing products with different architectures, reusing the same set of core assets. A Feature Model for Multiple ESB Product Lines Feature modeling is a domain analysis technique, which analyzes the commonality and variability in a particular domain. A feature model visually represents the commonality and variability of the domain [10]. Figure 1.1 shows the notation we used in the feature models presenting in this book.

Fig. 1.1. Feature Model Notation

Mandatory – child feature is required. Optional – child feature is optional. Or – at least one of the sub-features must be selected. Alternative – one of the sub-features must be selected. Based on the variability and commonality analysis presented in Sect. 1.1, a feature model for the multiple ESB product lines can be drawn as shown in Fig. 1.2.

Fig. 1.2. A Feature Model for ESB Product Lines

As per Fig. 1.2, an ESB product consists of a set of ESB services, an implementation for a particular ESB architecture, and a language to define ESB services and their compositions. The architecture can be a one of JBI,

6

1 Introduction

SCA, MQM, or Ad-Hoc. The services for an ESB are selected from an N number of ESB services. A service can be either a commonality or a product specific functionality. The first step for the creation of an individualized ESB for a customer is to select a suitable ESB architecture that can support the quality requirements of the customer. Secondly, it is needed to select a set of minimum services required to realize the integration solutions of the customer. Multiple ESB product lines are a set of single product lines where each one is formulated based on a particular ESB product variation. For example, an ESB product line based on JBI, an ESB product line for trading, an ESB product line for government and so on.

1.3 Contributions To formulate ESB product lines based on the feature model shown in Fig. 1.2, a platform that can suitably exploit the variability and commonality presented in the feature model should be invented. For this purpose, we present AO4ESB (Aspect Oriented Framework for an ESB), which is developed to provide a platform for multiple product lines of an ESB. Our platform is based on the principles of Aspect-Oriented Programming (AOP) [11], which modularizes crosscutting concerns. The structure and behavior of a crosscutting concern are generally scattered across the code base and tangled with the code related to other concerns. Aspects capture these crosscutting concerns and in turn, we capture ESB services as aspects. The reason behind the adoption of the AOP semantics is the fact that each ESB product offers mostly the same set of services but the source codes of service implementations are different and kept separately in each product. This situation is a kind of scattering and AOP semantics are suitable to address that. The foundation of our approach is the development of architecture independent generic components and transparent transformation of a single generic component into the components of different architectures. The AO4ESB comprises three main ingredients. 1. Aspect Library The aspect library plays the role of a universal ESB service library and consists of eight aspects namely log, crypto, caching, load balance, exception handling, monitoring, persistence, and proxy. 2. Aspect Weaver The aspect weaver enables a particular ESB product to use the functionalities offered by the aspects. It structures the aspects based on architecture styles that are suitable for the products that are going to use the aspects. 3. Aspect Composition and Definition Language(ACDL) The ACDL defines both the aspects and their compositions. In addition to the platform, we formulated an aspect development technique that can develop software elements, which should be reusable across

1.4 Summary

7

multiple product lines. An aspect adaptation technique that can transparently transform the aspects into the components of different architectures also was invented. Another key contribution is a design for multiple product lines of ESB, which can be potentially used as a basic model to formulate multiple ESB product lines.

1.4 Summary An Enterprise Service Bus(ESB) is the next generation EAI middleware. ESB products represent a wide range of architectural approaches such as service component architecture, java business integration, etc. We believe that if a single ESB vendor can produce each ESB variation, which the competitors develop, he or she can dominate the ESB infrastructure market. The customer base of an ESB is also heterogeneous and comprises various business domains. Each customer mostly prefers an ESB that can solve his or her integration problems efficiently. In other words, most customers would prefer individualized ESBs. To dominate the ESB market, we proposed a set of customizable ESB product families where each family consists of a particular ESB variation. The multiple product lines of an ESB can efficiently formulate such different ESB product families. Our main contribution is a platform that can potentially be used to formulate the multiple ESB product lines. Next, we turn our attention to the relevant literature for this research project including an ESB and other technologies used in this research, and the previous research attempts.

2 The Enterprise Software Ecosystems

History teaches everything including the future. – Lamartine The answers you get from literature depend upon the questions you pose. – Margaret Atwood Most often, previous research forms the foundation of a new research and the understanding of the existing knowledge related to a problem domain is inevitable to formulate a correct and optimal solution. This chapter explores the relevant literature for this research project, through reference to and critical analysis of them. This chapter is organized into six main subsections: related technology, aspects, AOP system architecture, aspect mining, AOP-based software product line, and related work.

2.1 Related Technology This research combines a set of newer technologies namely Enterprise Service Bus (ESB), Aspect-Oriented Programming (AOP), Software Product Line (SPL), and Domain Specific Language (DSL), and next sections comprehensively describe these technologies. 2.1.1 Enterprise Service Bus (ESB) An Enterprise Service Bus (ESB) is an infrastructure middleware, which supports the Enterprise Application Integration (EAI). The dominant service of an ESB is interoperability to enable the loose coupling between service consumers and providers. Typically, the services provided by an ESB (ESB services) are reusable and configurable.

10


A Definition of an ESB An ESB has multiple definitions and many of them are conflicting. Rosen, Lublinsky, Smith, and Balcer [2] define an ESB as follows. An ESB is an enterprise-wide extendable middleware infrastructure providing virtualization and management of service interactions, including support for the communication, mediation, transformation, and integration technologies required by services. By serving as a communication intermediary, an ESB lowers the coupling between service consumers and providers through providing the virtualization and management of service interactions. A Genaric ESB Architecture The architecture of an ESB makes it differ from traditional EAI systems. An ESB leverages the bus-based architecture, whereas the EAI systems use the hub and spoke architecture. In the hub and spoke architecture, the hub is the central processing unit that accepts the requests from applications, which are modeled as the spokes. Although this architecture separates the application logic from the integration logic of the applications, it suffers from limitations of scalability and a single point for failure. The decentralized bus architecture was innovated to overcome these limitations yet providing an efficient centralized control. The components of the bus architecture formulate a logical bus [2]. Figure 2.1 depicts a generic architecture of an ESB. In Fig 2.1, the run-time engine is a physically distributed infrastructure, which provides reliable communication services between service consumers and providers. Infrastructure services of the ESB include mediation, monitoring, security and so on. The run-time configuration allows the dynamic reconfiguration of the ESB components, whereas the administration and control facility provides a single point for controlling and monitoring the ESB components and their collaborations. Service Oriented Architecture (SOA) and ESB Service Oriented Architecture (SOA) is a paradigm for realizing the business processes, which span over heterogeneous enterprises. The fundamental concept of the SOA is the service whose interface and implementation have been clearly separated. Services expose distinct business functions and are composed to formulate business processes, which address complex business functions of enterprises. There are many different definitions for SOA and Josuttis [12] defines it as follows. SOA is an architectural paradigm for dealing with business processes distributed over a large landscape of existing and new heterogeneous systems that are under the control of different owners.

2.1 Related Technology

11

Fig. 2.1. A Generic ESB Architecture

Many researchers have identified an ESB as an infrastructure to implement SOA-based solutions, which solve application integration problems [2, 12]. Technologies for Realizing ESB To realizing an ESB, different ESB vendors have used diverse technologies and implementation approaches, and next sections explore four of those technologies. Web Service Web service is an application encapsulating business logic. Web service architecture supports the communication between these applications over a network and consists of a set of standards to provide interoperability. Josuttis [12] identifies five fundamental Web Services standards: XML (Extensible Markup Language), HTTP (Hypertext Transfer Protocol), WSDL (Web Service Definition Language), SOAP (Simple Object Access Protocol), and UDDI (Universal Description, Discovery, and Integration). XML and HTTP are general standards and others are web service specific standards. WSDL defines service

12


interfaces and SOAP provides a protocol for the inter web service communication. UDDI supports the publishing and locating services. Web Services are a popular technology for the implementation of SOA solutions. However, Web Services are not required to implement SOA [2, 12]. Java Business Integration (JBI) Java Business Integration (JBI) is an effort to create a standard-based architecture for integration solutions. It aimed to address issues with traditional B2B (Business-To-Business) and EAI systems due to their non-standard technologies [4]. In the JBI architecture, the components communicate by a message-based service invocation described using a standard service description language. The foundation of the JBI architecture is a central mediator providing the loose coupling between the components. The JBI architecture consists of following high-level components. •

•

•

Component Framework JBI supports two kinds of primitive components: Service Engines and Binding Components. Service engines implement business logic and binding components provides a communication infrastructure including the support for different communication protocols and transports. The JBI component framework allows these components to interact with the JBI runtime environment, which acts as a central mediator. Normalized Message Router Normalized Message Router decouples service consumers and providers, and is responsible for routing message exchanges among service consumers and providers. A message exchange is a JBI specific concept and contains a normalized message. Management Management provides the lifecycle management of the components and other artifacts.

Service Component Architecture (SCA) Service Component Architecture (SCA) is a set of specifications, which describe a model for building applications and systems using the SOA. SCA extends and complements prior approaches to implementing services and is built on open standards such as Web Services [13]. The primary concepts of the SCA are components and composites. Components implement business logic and provide standard interfaces that describe its functions. Furthermore, it consists of service references to consume the services offered by other components. A component implementation can be in any programming language. A composite, which implements a business process, is a collection of components assembled in a prescribed way defined by the Service Component Definition Language (SCDL). In additions to the concept of components and composites, there is a concept of binding, which encapsulates the mechanisms used


13

to communicate among components. SCA provides a wide range of bindings including web services and messaging. Chappell [5] introduces SCA including its fundamental concepts and the approaches of realizing it. Message Queuing Middleware (MQM) Message Queuing Middleware (MQM) provides an extensive support for reliable, asynchronous, and loosely coupled communication. In a MQM, applications communicate by inserting messages in specific queues. More importantly, applications can be physically distributed. Categories of ESB There are different ESB products developed based on different definitions and implementation approaches. Infosys research group [3] has categorized the current ESB products as follows. • •

•

EAI Based Products ESBs in this category are built top on the existing EAI products. Service Based Architecture The standards and specifications that support the service-based integration are the foundation for these ESBs. Java Business Integration (JBI), Service Component Architecture (SCA), and Message Queuing Middleware (MQM) are those standards and specifications. Web Service Standards Compliant Solutions These products are implementations of Web Service standards.

Woolley [7] compares ESB products based on architectural approaches and premises. It divides ESB products into two main categories: Enterprise SOA products and SOA-Lite products. It identifies integration/object broker products and SCA based products as enterprise SOA products, and JBI and Web Service based products as SOA-Lite products. 2.1.2 Aspect Oriented Programming (AOP) This section discusses the aspect-oriented programming (AOP) in detail. Separation of Concerns Typically, a complex software system consists of a set of components, which encapsulate application functionalities, more precisely concerns. A concern is any code related to a goal, feature, concept, or ”kind” of functionality [14]. Separation of concerns is a process of identifying and separating these concerns in any phase of the software lifecycle. Buschmann, Henney, and Schmidt [15] emphasize the importance of the separation of concerns as follows.

14


Separation of concerns is a key property of well-designed software. The more decoupled are the different parts of a software system, the better they can be developed and evolved independently. The fewer relationships the parts have to one another, the smaller the structural complexity of the software architecture. The looser the parts are coupled, the better they can be deployed in a computer network or composed into larger applications. In other words, a proper partitioning of a software system avoids architectural fragmentation, and developers can better maintain, evolve, and reason about it. Furthermore, it notes the relation of separation of concerns with the product-line architectures as: The basis for sustainable product-line architecture is a clear separation and encapsulation of different system concerns, be they functional in nature or infrastructure-related. Although separation of concerns is required for a sustainable software system, the achievement of it is difficult, due to the crosscutting nature of many concerns of the system. Crosscutting Concerns Typically, many concerns of a system depend on other concerns, and are orthogonal to each other. For example, a message sending function may need security, synchronization, logging and so on, whereas the logging concern may also need security to support the secure logging. Effectively, one concern is used by other concerns. This phenomenon is called the crosscutting. The result is a scattering of common codes. Clarke and Baniassad [14] define the crosscutting concern as: A concern triggered in multiple situations or whose structure and behavior are scattered across the code base and tangled with code related to other concerns. Figure 2.2 shows the crosscutting phenomenon. As shown in Fig. 2.2, all core functions need the security and logging concerns. Therefore, the core functions need to call explicitly those concerns or to duplicate the code of those concerns. An adequate solution to achieve the separation of concerns is a mechanism to identify, separate, and modularize the crosscutting concerns, and to compose them back to the dependent concerns. Aspect-Orientation Programming (AOP) offers such a solution. AOP provides a different view of modularity, and modularizes the crosscutting concerns, which are the results of the horizontal decomposition of the system functionality. AOP enables to define the systems base concerns and crosscutting concerns separately and to compose them in a prescribed way to make the final system.


15

Fig. 2.2. Crosscutting Phenomenon

AOP Terminology This section describes the terminology used in the AOP, based on a pioneer research on AOP by Kiczales, et al [11]. Components. Components capture the system properties that can be cleanly abstracted out by using the Object-Oriented Programming (OOP), and present the reusable functional units resulted from the vertical decomposition of the system functionality. Components are more generalized and encapsulated. Aspects. Aspects are the system properties that cannot be cleanly abstracted out by using the OOP. Aspects do not represent the units of the systems functional decomposition, but rather the properties that affect the performance or the overall behavior of the components. Tangling. Tangling is taking place in a system that does not use the AOP. In tangling, the aspects are scattered throughout the components, and the resulted tangled code is extremely difficult to maintain. Join Point. Join Point belongs to the components, and the aspects are weaved at the join points. This is the location that the main logic and aspects functionalities are interacted. Point-cut. Point-cut specifies the join points using a kind of language construct such as annotations and configuration files. Advice. Advice instructs about how behaviors will be weaved at the joins points. There are three main types of advices: before, after, and around. Before advice - Executes aspects prior to the join point. After advice - Executes aspects following the join point. Around advice - Surrounds the join points execution with the aspects execution. Figure 2.3 shows the relationship among aspects, advices, point-cuts, and joint points. As shown in Fig. 2.3, the joint points are in the running program, and are selected based on the point-cuts. Advices instruct to add the behaviors of the aspects into the main program at the joint points.

16


Fig. 2.3. Aspects, Advices, Point-cuts and Joint Points

Goals of the AOP The main goal is to provide a way to achieve an improved separation of system properties. More preciously, the goal is to provide a strategy to abstract the system properties into components and aspects appropriately, and to compose the components and aspects to build the overall system. In the AOP, the separation includes the separation of a component from other components, an aspect from other aspects, a component from aspects and an aspect from components. The main ingredients of an AOP-based system are: Component Language and Program, Aspect Language and Program, and Aspect Weavers. The overall system creation process is declarative and automotive. First, it generates join points using components, and then weaves aspects as appropriately at the join points, and finally it generates the overall system. Aspect Weaving Strategies Typically, an aspect weaving process either adds new classes and methods, or modifies existing classes and methods. Piveta and Zancanella [16] have identified four strategies of the aspect weaving: weaving through inheritance, weaving through association, weaving through the Decorator design pattern, and weaving through reflection. (In the following discussion, the class that needs functionalities of aspects is named as the main class.) •

•

Weaving through Inheritance This method uses the inheritance concept of the OOP and generates a subclass for a given main class. The subclass overrides methods of the main class and implements functionalities of aspects in the overridden methods. The advantage of this approach is the preservation of the original main class. Inheritance anomalies are the main disadvantage. Weaving through Association Association is used to add behaviors described in aspects. The affected


•

•

17

methods in main classes are modified so that those can call methods defined in the aspects to get required additional behaviors. The main advantage is that new classes are not created, neither objects of the main classes are modified. Weaving through the Decorator Design Pattern Decorator[17] design pattern attaches additional responsibilities to an object dynamically. In this strategy, new classes are generated with references to main classes and the generated classes act as decorators for the main classes. The functionality of an aspect is added as a decoration. The advantages of this approach include the preservation of the original class and advantages of the Decorator pattern over the inheritance such as a flexible alternative for the sub-classing. Weaving through Reflection In this strategy, meta-classes are generated for each main class and the generated meta-classes implement functionalities of aspects. This method can leverage the existing support for the reflection in programming languages such as Java. A main advantage in this approach is the non-invasive addition/modification of classes. The disadvantages include the lack of support in some programming languages for the reflection and the negative effects on the performance.

Aspect Weaving Approaches In the research literature, two main approaches for the aspect weaving can be identified: static weaving and dynamic weaving. This section summarizes those approaches based on a discussion from Forgac and Kollar [18]. Static Weaving. Static weaving modifies the source code of a class by inserting aspect specific codes at join points. Figure 2.4 presents a static weaving approach.

Fig. 2.4. Static Weaving

18


In Fig. 2.4, the inputs to the aspect weaver are both aspects and the source code of the class, which needs functionalities of the aspects, and the output from the aspect weaver is a woven code. The compiler compiles the woven code to make an executable program. The result of the static weaving is a highly optimized woven code. A disadvantage in the static weaving is the difficulty of identifying and changing aspect-specific statements in the woven code. AOP implementations such as AspectJ, AspectC, and HyperJ use the static weaving approach. Dynamic Weaving. Dynamic weaving modifies a program while it is running. Figure 2.5 depicts a dynamic weaving approach.

Fig. 2.5. Dynamic Weaving

The inputs to the aspect weaver are aspects and an executable program created by compiling the source code of the class that needs functionalities of the aspects. The aspect weaver modifies the executable program appropriately to augment it with the aspects functionalities. The dynamic weaving approaches, which use the Binary Component Adaptation (BCA) and the Java Object Instrumentation Environment (JOIE), replace the system class loader of a Java Virtual Machine (JVM). The system, which uses the dynamic weaving, must be efficient under normal operations and in the advice execution, and must enforce a secure and atomic weaving. JBoss AOP and AspectWerkz use this approach. 2.1.3 Domain Specific Language (DSL) A Domain Specific Language (DSL) provides a way for optimally describing the problems belong to a specific domain so that the experts in the corresponding domain can easily understand, use, and validate the design and implementation of both the problems and their solutions. Furthermore, a DSL typically represents the domain knowledge and enables the conservation and reuse of that knowledge. Deursen, Klint, and Visser [19] define the DSL formally as follows.


19

A domain-specific language (DSL) is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain. According to the definition, a DSL should possess an extensive capability to express effectively the problems in a particular domain. A DSL allows being in any form such as textual or graphical. A graphical DSL is a meaningful graphical representation of each language construct of the DSL, and is a tool for maintaining the DSL itself and the system that uses the DSL. Fowler [20] describes this usage of a DSL in detail. Figure 2.6 shows a process of generating a UI from a DSL.

Fig. 2.6. Projection of DSL into UI

The first step in the process shown in Fig. 2.6 is to read and parse the DSL source file. The second step builds the semantic model of the DSL. Finally, the semantic model is used to generate a UI as well as source codes that are in a general-purpose language such as Java. 2.1.4 Adaptive Middleware This subsection attempts to identify relationships between the adaptability of middleware, and the AOP and design patterns. An adaptable middleware enables modifying behaviors of an application after the application is developed, in response to changes in functional requirements or operating conditions [21]. Sadjadi and McKinley have identified two types of adaptations provided by an adaptable middleware.

20

•

•


Static Adaptation Middleware in this category enables the adaptation of an application at the compile time or startup time, and is divided further into two subcategories: customizable and configurable middleware. Customizable middleware can adapt an application during the application compilation, and static AOP approaches are examples for this category. Configurable middleware can adapt an application during the application startup time, and configuration files are examples for this category. Furthermore, the configurable middleware enables to reconfigure and to redeploy the adapted system. Dynamic Adaptation Dynamic middleware can be divided into two categories: tunable and mutable middleware. Tunable middleware can adapt an application at the startup time and the mutable middleware can adapt an application at the run time. Dynamic AOP is an example for the mutable middleware.

In additions to the types of the adaptations, Sadjadi and McKinley [22] have identified four paradigms, which support the creation of an adaptable middleware: computational reflection, component-based design, and AOP and software design patterns. Computational reflection refers to a programs ability to reason about, and possibly alter, its own behavior. With this approach, an application can change its own behavior or an observer of an application can change the behavior of the application. In a component-based design, a system consists of a set of reusable and configurable components, and EJB (Enterprise JavaBeans) and CORBA (Common Object Request Broker Architecture) based systems are examples for the component-based design. Compositional adaptation involves not only changes in a program flow, but also the run-time re-composition of the software itself. Separation of concerns, computational reflection, and component-based design are the main technologies supporting the compositional adaptation and the AOP can provide separation of concerns. 2.1.5 Software Product Line (SPL) A Software Product Line (SPL) refers to a portfolio of similar software systems that share a common set of core assets. Clements and Northrop [23] define the SPL as follows. A set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. The benefits that can be gained from software product lines include the increase in productivity and quality, and the decrease in cost and time to market.

2.2 Aspects

21

A Software Product Line Engineering (SPLE) is an engineering discipline for creating and managing effective SPLs. The main concepts of the SPL are the mass customization and the use of a platform. Mass customization enables to create many variants of a product, targeting each variant for a particular customer base. Platform enables to create the entire products in a product line from a common set of core assets [24]. A SPLE is broadly divided into two processes. •

•

Domain Engineering Activities in this process are establishing the platform and the analyzing and specifying of the commonality and variability in the product line. Gacek and Anastasopoules [25] have analyzed the approaches of the variability management at the code level. It includes AOP, design patterns, reflection, and object-oriented concepts such as inheritance, method overloading, and delegation. Buschmann, Henney, and Schmidt [15] also have emphasized advantages of design patterns and separation of concerns for designing, implementing and managing sustainable product-line architectures. Application Engineering Application Engineering is the process of building products in the product line based on the platform, and the commonality and variability analysis. This process involves activities such as the selection and configuration of core assets according to the product specification of each product.

Section 2.5 will discuss the relationship between the AOP and the SPL in detail including previous research attempts.

2.2 Aspects Next sections describe the functionalities and some of the existing design and implementation approaches of ten aspects that a typical ESB needs. In this research project, an aspect is used to modularize an ESB service. Aspects have been selected base on the usage in existing ESB products. Logging, security, cache, exception handling, validation, persistence, transaction, reliability, load balance, and monitoring are considered and discussed. 2.2.1 Logging Aspect An effective yet simple logging strategy is inevitable for a middleware to record events and statistics related to the operations of it. Logs are records of the events occurring within an organizations systems and networks, and are composed of log entries where each entry contains information related to a specific event that has occurred within a system or network [26]. The content of a log

22


record depends on the application, which generates the log record. In a messaging system, it typically consists of discrete portions of requests, responses, and fault messages. Log records enable auditing, which is a process of analyzing log records to present information about the system in a clear and understandable manner. Auditing is useful for diagnosing problems and analyzing security states of the system including detecting attacks, fraud, and other malicious activities. Next sections describe some requirements and best practices for a logging component, based on [26, 27]. Log Categorization and Prioritization. Log categorization needs to be more generic to allow the evolution of it, based on target contexts such as traces in backend services, UI events log, messages and so on. Priorities can be defined in advance in a context-neutral way, and many existing logging systems have a same set of priorities such as debug, information, warning, and error. The categorization and prioritization make the auditing process efficient by reducing both the number of log records and the content of a log record. Log Filtering. Log filtering reduces the load on the system and the storage, which needs to keep logs. Keeping only meaningful information makes the auditing process efficient. A wide range of criteria for the log filtering is needed to an ESB and the log filtering based on the content of a log record, user information, categories, and priorities are suitable candidates. Minimum Runtime Overhead. Logging can make a significant impact upon the performance of a system and the impact is typically proportional to the size of the content of a log record. The purpose of logging determines the content of a log record. For example, the logging for diagnosing a problem in a production environment needs a complete message. This kind of situation is unavoidable. An asynchronous model for the logging or a passive logging is a solution to reduce the effect on the run-time performance of the system due to the logging. Therefore, a logging component should support both the synchronous and asynchronous models of the logging. Secure Logging. Log record may consist of sensitivity information such as passwords and credit card details. Logging system may keep such information to support the non-repudiation. Therefore, the protection of the log records from breaches of their confidentiality and integrity is mandatory. A suitable solution is to apply required security operations prior to save the log records in a destination. Configurable Log Formatters and Log Destinations. The destinations of log messages need to be available from in-memory to persistence storages such as database systems, message queuing systems, and file systems. The formats of a log record can be in text, XML, SOAP, or custom.

2.2 Aspects

23

A Design for a Logging Component Figure 2.7 shows a basic design of the Microsoft Enterprise Library Logging Application Block [27], which is a configurable and extensible logging component.

Fig. 2.7. A Design of the Logging Application Block

LogEntry class is the basic unit that captures the logging information. Logger is a facade providing all logging methods, and it hides the implementation class, LogWriter. TraceListeners are the destinations of log entries and LogSource routes the log entries to the trace listeners. 2.2.2 Security Aspect The importance of security is widely acknowledged for any software systems. A proper security solution must support all major security objectives: confidentiality, integrity, and availability. Security is not an add-on feature and a system should provide comprehensive approaches for achieving it. Hinton, Hondo, and Hutchison [28] discussed the relationship between the ESB and security principles such as authentication, access control, and message protection. That research presents a layering approach, where each layer provides a different level of security. In the transport layer, ESB should provide the transport layer security, and should establish a trust relationship with service consumers. In the message level, ESB may provide additional security services including message encryption, digital signature verification, identification, and authentication. Huang, Wang, and Zhang [29] attempted to implement a security aspect library based on the AspectJ and the Java security API. It consists of security aspects, which provide encryption/decryption, authentication, authorization, and security audit.

24


A Design of a Security Component MEL provides two application blocks for the security domain: Security and Cryptography. The Security Application Block simplifies and standardizes the way of providing authorization and caching a user’s authorization and authentication data. Authorization information can be located in different locations including directory services, databases and so on. Figure 2.8 depicts a high-level design of the Security Application Block.

Fig. 2.8. A Design of the Security Application Block

In the design shown in Fig. 2.8, SecurityCacheFactory creates security cache providers, which provide the ability to save authenticated identities, principals, and profiles. AuthorizationFactory creates authorization providers such as AuthorizationManager (AzMan) which is a standard interface for maintaining active directory roles, groups, tasks, and operations. The Cryptography Application Block encapsulates the cryptographic functionalities and exposes a standard model to use those functionalities within applications. Figure 2.9 depicts a high-level design of the Cryptography Application Block. In Fig. 2.9, Cryptographer is a facade that gives an application the ability to create hash values of some data, to compare hash values, to encrypt data, and to decrypt data. The provider factories create hash providers and symmetric crypto providers. DPAPI is the Windows Data Protection API, which supports a password-based data protection. 2.2.3 Caching Aspect Effective caching is a key to achieve an improved performance of a distributed system as it reduces the latency. On the other hand, it serves as a scalability technique as it reduces the load on a server. The consistency of a cache is inevitable for reliability. Therefore, the goal of a caching component is to provide a maximum perceive performance while maintaining the consistency.

2.2 Aspects

25

Fig. 2.9. A Design of the Cryptography Application Block

For a distributed system, the caching is applicable in every layer: user interface, business logic and data access. Next sections describe some required features for a cache component based on [30, 31]. Loading a Cache. There are two main strategies for loading a cache: proactive loading and reactive loading. Proactive loading populates a cache with all required data usually at an application or a process startup time. As the proactive loading may slow down the system startup, it is better to use an asynchronous programming model. Asynchronous pull loading and notificationbased loading are some approaches of the proactive loading. In the asynchronous pull loading, an agent running periodically populates the cache and the notification-based loading is an event-driven approach where applications services notify the cache component of state changes so that the cache component can retrieve changed data. Reactive loading retrieves data on demand as an application requests data, and then caches it for future requests. It is implemented using synchronous programming models such as synchronous pull loading. Expiration. An expiration policy specifies how long data should stay in a cache before the cache automatically removes it. There are two categories of the expiration policy: time-based expirations and notification-based expirations. The time-based expirations remove stale data based on either relative or absolute times, and the notification-based expirations remove stale data based on instructions from an internal or external source such as a file, a folder, or any other types of data sources. Eviction. A cache has a threshold defining the maximum number of cache items. When the cache exceeds this limit, it should remove existing cached items. This allows managing the cache to ensure that storage, memory, and other resources being used efficiently. There are two categories of eviction

26


strategies - explicit flushing and scavenging. Least Recently Used (LRU) and Least Frequently Used (LFU) are widely used two algorithms to detect candidate cache items for removing. Cache Storages. The cache component should provide both volatile and nonvolatile cache storage. Non-volatile storage includes disk-based data storages such as files or databases. Securing a Cache. Data tampering and spoofing are two main security attacks related to a cache. By signing and verifying cache items, it is possible to prevent the data tampering and the encrypting can prevent the spoofing. Monitoring a Cache. Cache usage and performance statistics are useful to optimize a caching solution. The typical parameters of statistics metric of the cache include the total cache size, the cache hit/miss ratio and insert, update and retrieve times. A Design for a Logging Component Caching Application Block supports both in-memory and disk cache. The expiration and eviction of the cache is a policy-based approach. A cache is only consistent regard to application and is reliable as it is thread safe and exception safe. Cache component can work together with other components such as security and cryptography in order to support the security requirements of the caching. Figure 2.10 shows a basic design of the Caching Application Block. In Fig. 2.10, CacheManager manages caches and the backing stores, which provide storages for cache items. IsolatedStorageBackingStore provides the ability to persist cached data to isolated storages and NullBackingStore provides volatile cache storage. Both the expiration and eviction are background tasks. 2.2.4 Exception Handling Aspect Strategic exception handling is a key to the reliability of a software system. Software exception handling can improve the software fault tolerance by preventing exceptional conditions from becoming software faults. Exceptions occur mainly due to programming errors and temporally resource failures. Next sections discuss the required features of an exception-handling component based on [27]. Replacing an Exception. Replacement of an exception is mandatory when the original exception contains sensitivity information such as passwords, credit card details, and financial information. It also a best practice to hide technical errors and to map technical errors to business rules because end-users should view technical issues as business problems. Typically, the business rule statement is the error message [32].

2.2 Aspects

27

Fig. 2.10. A Design of the Caching Application Block

Wrapping an Exception. Wrapping one exception around another is useful in situations where the original exception must be mapped to a new exception type prior to use by other tiers within the architecture of an application. Furthermore, this strategy inherits the advantages of the replacing an exception. Logging an Exception. Logging an exception information and associated context information is vital for diagnosing problems at later. Furthermore, it can be used with either replacing or wrapping exception handlers to log the original exception prior to replace or wrap it. To implement this exception handling strategy, the exception-handling component should use the logging component appropriately. Retrying on Exception. By automatically retrying operations that are expected to fail under certain conditions, the fault tolerance of a system can be enhanced. This is a proven strategy for handle transient failures. The logic of retrying should be applicable to both data access failures and communication failures, which are two common situations in an ESB. Luo, Sheth, Kochut, and Miller [33] discussed the exception handling in workflow systems. According to that research, the masking, propagation and recoding are strategies to handle exceptions. Masking includes corrective actions such as ignore, retry, workflow recovery operations, and modifications of workflows.

28


A Design of an Exception Handling Component The Exception Handling Application Block of the MEL provides a consistent way for processing exceptions that occur in all architectural layers of an enterprise application. This application block addresses common exception handling scenarios such as logging exceptions, wrapping exceptions, re-throwing exceptions, alerting on exceptions, and replacing exceptions. A basic design of this application block is in Fig. 2.11.

Fig. 2.11. A Design of the Exception Handling Application Block

In Fig. 2.11, ExceptionPolicyEntry manages exception handlers for each exception type. ExceptionPolicy keeps ExceptionPolicyEntry instances, and selects the suitable instance based on the exception occurred. 2.2.5 Validation Aspect Validation is a secure programming best practice that can prevent the exploitation of vulnerabilities including an altering of control and data flows, an arbitrary control of a resource or an arbitrary code execution and injection. Typically, applications validate the objects in inputs, outputs, parameters, and variables. These objects can be in any form. For example, an input can be a database query or an XML document that is an input to a transformation engine. For a message oriented system, the grammar of the message is the foundation of validation techniques. For XML messages, it is either schemas or Document Type Definitions (DTD). Gruschka and Luttenberger[34] have used a schema-based message validation to prevent DoS attacks against Web Services. The implementation was an XML validation engine that used an eventbased XML processing to avoid the effects of the validation on the total response time.

2.2 Aspects

29

A Design of a Validation Component Validation Application Block of the Microsoft Enterprise Library is applicable to validation scenarios such as input validation, output validation, sending meaningful context aware error messages on validation failures and so on. A basic design of the validation application block is in Fig 2.12.

Fig. 2.12. A Design of the Validation Application Block

In Fig. 2.12, Validator validates data types and ValidationFactory creates validator instances. The string null check validator and the number range validator are some examples for the implementations of Validator. 2.2.6 Persistence Aspect Persistence component should provide secure and reliable data storages and an API for data access. Many other aspects require the persistence aspect. For example, the logging aspect can use the persistence aspect to store log records, whereas the cache aspect may use it as cache storages. On the other hand, a messaging system may use it to store data extracted from the message or the message itself. Little research attempted to implement persistence concern using AOPbased approach. Rashid and Chitchyan [35] have used AOP techniques to effectively modularizing persistence concerns. They have proven that by using AOP, the persistence aspect that exhibits a high degree of reusability, can be developed. A Design of a Persistence Component Data Access Application Block of the MEL encapsulates common data access functionalities, and applications can use it for situations such as reading data

30


for display, passing data through application layers, submitting modified data back to the database system and so on. This application block implementation supports the connection management, security and cache management. Figure 2.13 shows a basic design of the data access block.

Fig. 2.13. A Design of the Data Access Application Block

In Fig 2.13, Database class is an abstract class that has concrete three implementations: GenericDatabase, OracleDatabase, and SqlDatabase. A Database object can be created by using DatabaseFactory. DBConnection is the base class for connecting to a relational database and ParameterCache class allows parameter information of stored procedures to be cached. 2.2.7 Transaction Aspect Transaction support is an important requirement for an ESB. A transaction is a set of operations executed as a single unit and must preserve ACID properties: atomicity, consistency, isolation, and durability. ChainBuilder ESB [36] provides an extensive support for transactions. It supports three types of transaction worthwhile to an ESB namely local transactions, global transactions and compensating transactions. A local transaction represents a unit of work on a single connection to a data source managed by a resource manager, and JMS (Java Message Service) and JDBC (Java Database Connectivity) are examples for local transactions. In a global transaction, there is an external transaction manager. Applications update data sources and the global transaction manager coordinates these updates to corresponding data source managers. Java Transaction API (JTA) is an example for a global transaction. In a compensating transaction model, a compensating transaction can semantically reverse effects of early business activities. Walls and Breidenbach [37] have discussed the mandatory properties of a declarative transaction. The discussion is based on a concept of transaction attribute, which describes the way of applying transaction policies to a method.

2.2 Aspects

31

There are four parameters of a transaction attribute namely propagation behavior, isolation levels, transaction timeout and rollback rules. A propagation behavior defines the boundaries of a transaction with respect to the client and to the method. An isolation level defines the impact of a transaction due to the activities of other concurrent transactions. A transaction timeout provides a semantic to enable declaring a transaction that automatically rolls back after a certain number of seconds. Rollback rules are a set of rules that define what kinds of exceptions would prompt a rollback operation. 2.2.8 Fault Tolerance Aspect Fault tolerance and reliability aspects represent very broad areas, and it is desirable to identify roles of them in an ESB domain. Poozhikunnel [38] has explained failure scenarios that ESB can handle to improve the fault tolerance of it. Three of them are: 1. Destination Cannot be Reached This needs a mechanism for storing messages and for retrying based on a policy, which defines the number of retry attempts, timeout between consecutive attempts and so on. 2. Message too Large If the message is too large, it could result in a buffer overflow or a truncated message. The verification of the size of a message helps the sender to truncate the message and to send it in smaller chunks. The receiver also can get similar advantages. 3. Message is Corrupted Sometimes the sender can send a message that is not correct and the schemas in an ESB could verify this. A schema defines a grammar to verify the message syntax. Whenever the verification fails, the ESB can send an appropriate message back to the sender to inform to take necessary actions such as resending the correct message. 2.2.9 Monitoring Aspect The monitoring is one of the main services that should be provided by an integration middleware. An ESB needs to monitor the messages in transit, message processing errors, and the performance of the system. There are typically two types of monitoring important to the ESB: message monitoring and Service Level Agreement (SLA) monitoring. Message Monitoring. Message monitoring is applicable to both message exchanges among the components of an ESB and end-to-end message exchanges between clients and servers. The ESB can have another system that observes it. QoS Observer [38] is a pattern for doing the message monitoring using an external system, and Fig 2.14 shows a high-level architecture of the QoS observer.

32


Fig. 2.14. QoS Observer Pattern

As shown in Fig. 2.14, the QoS observer observes the message flow, and when it observes a fault, it raises events to notify any systems that administrate the operations of the ESB. SLA Monitoring. The validation of the Service Level Agreement (SLA) is a main aspect of an ESB. Figure 2.15 shows a basic SLA monitor. The more information about the SLA monitoring is in [39].

Fig. 2.15. A SLA Monitor

In the approach shown in Fig. 2.15, the evaluator processes the information obtained to check whether the SLA is satisfying. When the evaluator notices SLA violations, it notifies handover-tasks to inform to take recovery actions. For each violation, the SLA Violation Notifier sends notifications to all interested parties to take appropriate actions. Hohpe and Wool [40] have discussed the system management patterns for a message-based system. They categorize the system management patterns into monitoring and controlling, observing and analyzing message traffic, and

2.2 Aspects

33

testing and debugging. The primary pattern is the Control Bus, which is useful for implementing a monitoring aspect for an ESB. It provides an abstraction to carry out control messages including configuration parameters, heartbeat message, test messages, and statistics. 2.2.10 Load Balance Aspect Load balancer distributes incoming application traffic across multiple destinations to provide a virtual system with the aggregated capabilities of each destination. Upon receiving a request, the load balancer should identify a destination to send the request. This involves two steps: identify a set of destinations with good health and select a single destination out of them. Identify a Set of Destinations with Good Health Health check provides the capability to detect the health of destinations. Kopparapu [41] has discussed the concepts of health checks in detail. The best practices of the heath checking in the load balancing include the use of standard based health checks and keeping the amount of health checks that a load balancer performs as little as possible. Health checks fall into two categories: in-band monitoring and out-band monitoring. 1. In-band monitoring Determine and monitor actual servers using the natural message traffic flow. For example, the missing of TCP ACKs (Transmission Control Protocol Acknowledgment) or the receiving of HTTP error codes indicates that the server is in an unstable state. 2. Out-band monitoring This approach uses a separate control channel. An agent in the load balancer observes the control channel, and makes decisions based on information in the control channel. This proactive approach usually is implemented through an asynchronous model. Select a Destination The load balancer uses a load distribution algorithm to select a destination, based on the load conditions on different destinations. A set of widely used load balancing algorithms are: 1. Random Random load balancing method randomly distributes a load across destinations available, picking one via random number generation and then sending the current request to it. Although this algorithm is simple to implement, the load balancing may not be optimal.

34


2. Round-Robin Round-Robin algorithm forwards each new request to the next destination in line, eventually distributing requests evenly across the array of destinations being load balanced. Although this algorithm distributes requests evenly, the capabilities of the destinations may not be utilized appropriately. 3. Weighted Round-Robin With this method, the number of requests that each destination receives over time is proportional to a ratio of the weights for the destinations, defined statically in a configuration. This algorithm does not consider the advanced load balancing requirements such as processing times for each request. 4. Dynamic Round-Robin This is similar to the Weighted Round-Robin; however, the weights are based on the continuous monitoring of the destinations and are therefore, continually changing. This algorithm considers the advanced load balancing requirements such as processing times for each request. Therefore, this algorithm can utilize the capabilities of the destinations. Server Affinity and Session Persistence Server affinity is a load-balancing system’s ability to manage a user’s requests, to either a specific server or any server, depending on whether session information is maintained on the server or at an underlying database level [41]. The purpose of the server affinity is to minimize the number IP sockets opened between external clients and server instances in a cluster. In the session persistence, the load balancer saves all the sessions from a given user to the same server. In order to perform session persistence, the load balancer must know two things: how to identify a user, and how to recognize when an application transaction begins or ends. When the load balancer receives a new connection, it can either load balance it or perform the session persistence. When performing the session persistence, the load balancer sends subsequent connections to the same server regardless of the load on that server. Session persistence violates load balancing. Load balancing involves sending a request to the server with least load, whereas the session persistence involves sending a request to the same server as before, regardless of the load of the server. In order to get the best scalability and response time, a system should use a minimum level of the session persistence that fulfills application requirements, so that the system can get more loads balancing [41]. Fiorano Software [42] has suggested some of the best practices for the load balancing. The best practices include scaling by adding more peers/servers to the network, scaling by distributing the load across multiple service instances, scaling via transparent resource addition, changing processes dynamically, and

2.3 AOP System Architecture

35

parallelizing data flows. Figure 2.16 depicts the load balancing best practice: scaling by distributing the load across multiple service instances.

Fig. 2.16. Scaling by Distributing Load across Multiple Service Instances

In the approach shown in Fig. 2.16, services can be either located on service providers servers or in ESB peers. An advantage of this approach is the possibility of masking scalability and performance issues occurred when a particular service is becoming a bottleneck. Drawbacks include the increasing in the message throughput and the possibility for breaking in the message ordering.

2.3 AOP System Architecture Next sections discuss four architectures that are used by many AOP-based systems. From these different architectures, the Proxy Factory based architecture and the architecture of the Policy Injection Application Block of the MEL significantly influence the foundation architecture of the AO4ESB. From these different architectures, the Proxy Factory based architecture and the architecture of the Policy Injection Application Block of the MEL significantly influence the foundation architecture of the AO4ESB. 2.3.1 Proxy Factory Based Architecture Proxy Factory takes inputs as an object, interfaces, advices, and aspects, and then creates a proxy for the given object that offers the given interfaces. This makes the proxy and original object almost similar. Therefore, the applications that use the original object are not aware of the aspects weaving. This property enables to introduce aspects into the system in a transparent manner with less effort. Walls and Breidenbach [37] provide a basic description about the proxy factory. Figure 2.17 depicts the functionality of a proxy factory.

36


Fig. 2.17. The Proxy Factory Approach

2.3.2 Policy Injection Application Block Architecture The architecture of the Policy Injection Application Block of the MEL enables to specify crosscutting behaviors of objects in terms of a set of policies. A policy is a combination of a series of handlers that execute when a client code calls the methods of an object. The result is a mechanism for executing a chain of handlers around the execution of the methods of an object. This chain of handlers is a pipeline, and the handlers within each pipeline are reusable and independent of the object. These handlers can be other Enterprise Library Application Blocks such as logging, security and so on. Figure 2.18 depicts the process for creating and accessing a proxy.

Fig. 2.18. Handler Pipelines of the Policy Injection Application Block

2.3 AOP System Architecture

37

As shown in Fig 2.18, a client creates a proxy using the factory, and calls a method of the proxy. The proxy executes a set of handlers both before calling the method of the object and after calling the method. 2.3.3 Composition Filters Model Composition Filters (CF) Model [43] uses the concepts of filters to express crosscutting concerns. Two main advantages of this approach are the modularity of filer designs and orthogonal behaviors each filter implements. The modularity makes the filters independent of implementations and orthogonal behaviors make the semantics of the filters are different. Orthogonal extensions allow the composition of the filers so that it is possible to implement complex functionalities as a composite of independent filters. Figure 2.19 shows a basic structure of the CF model.

Fig. 2.19. The Basic Structure of the Composition Filters Model

In CF approach, internal objects are instantiated and encapsulated within the CF object, whereas externals objects exist outside the object, such as global or shared objects. Methods identify accessible methods of the object, and conditions test whether a message should be accepted or rejected. The

38


filters define the behaviors of the object as a composition of the behaviors of its implementation, its internals, and its externals. 2.3.4 An AO Framework in OOP Environment This section explores the design of an aspect-oriented framework presented by a previous research [44]. The design and the implementation of the framework support to achieve improved separation of concerns, and provide adaptability. Abstracting aspects, creating aspects, and registering new aspects and components at runtime are some of the functionalities provided by the framework. Furthermore, the use of design patterns for designing and implementing the framework made it adaptable. Figure 2.20 depicts the basic design of the framework.

Fig. 2.20. An AO Framework in OOP Environment

In Fig. 2.20, AspectModerator takes a role of an automatic aspect weaver, and weaves components and aspects appropriately. FunctionalityProxy creates proxy objects, which intercept the access to the primary concerns of the original class, whereas AspectFactory creates aspects. The aspect moderator evaluates the precondition of an aspect prior to call an aspects functionality. After calling the aspects functionality, it evaluates the post condition of the aspect.

2.4 Aspect Mining

39

2.4 Aspect Mining This section discusses aspect mining including its importance and approaches for performing it. We also outline the relationship between refractoring and aspect mining. 2.4.1 Need for Aspect Mining Aspect mining is a process of identifying tangled and scattered codes or crosscutting concerns. Loughran and Rashid [45] discussed the importance of the aspect mining. By discovering and separating both main concerns and crosscutting concerns, the aspect mining can support the design and implementation of adaptable and extensible systems. Aspects are always crosscut systems base functionalities thereby making the validation of the design and implementation of the aspects are expensive activities. Therefore, separation of the aspects is cost effective. By discovering the commonality and variability of a product line, the aspect mining can support to formulate a successful product line. Aspects can modularize the orthogonal functionalities of a system. By composing these orthogonal functionalities appropriately, it is possible to produce a family of customized yet related products. 2.4.2 Aspect Mining Techniques Aspect mining mainly aims at refractoring systems into AOP-centric systems. There are two main approaches for the aspect mining: code duplication based approaches and the use of scattering [46]. Approaches Based on Code Duplication This class of approaches is based on the static analysis of the code. There are two main techniques belong to this class. 1. Clone Detection Techniques The token-based clone detection applies a lexical analysis to the source code to find tokens and subsequently uses those tokens as a basis for the clone detection. This is a manual process where gets user inputs and then finds the occurrences of them in the source code. The main downfall of this method is that requires the user to have an in-depth understanding of the source code to select a token that can return meaningful results from the clone detection. 2. Aspect Mining Using Formal Concept Analysis The formal concept analysis identifies meaningful groupings of elements that have common properties. This is a kind of cluster analysis technique that tries to group elements with shared properties together and then to identify their inter group relationships.

40


Approaches Based on Scattering There are two main techniques based on the scattering. 1. Fan-in Analysis This assumes that the amount of calls (fan-in) is a good measure for the importance and scattering of the discovered concerns. In this method, the number of calls has been made to a particular method from any place of the code are measured. 2. Analysis of Recurring Patterns of Execution Traces This method analyzes the trace logs of the system to find out recurring execution patterns, which could point to the before/after/around AOP advices of aspects. 2.4.3 Feature Modeling Feature modeling is a domain analysis technique, which analyzes the commonality and variability in a domain to develop highly reusable core assets for a product line. Features may belong to each level of the software system including high-level system requirements, architectures, and subsystem and component levels. Because the features are the commonality or the variability in the product line, in an AOP-based product line approach, aspects can be used to modularize such features. Therefore, the feature modeling is a suitable approach to identify aspects that crosscut the products in a product line. Conejero and Hernandez [47] have adapted the feature modeling to analyze crosscutting concerns of a product line. The feature-oriented analysis was the first activity in the process, and was used to identify functional and operational features in the product line. 2.4.4 Aspect Mining and Refactoring A legacy software system is simply an old system that remains in operation within the organization. The maintenance of legacy systems is extremely difficult due to the lack of documentation and the limitation of existing interfaces for the adaptation or the integration with new systems and technologies. The approaches such as reengineering, reverse engineering, design patterns, and the aspect-oriented software development (AOSD) can be used to maintain such systems [48]. Colyer, Blair and Rashid [49] have discussed the application of AOSD techniques to achieve the goals of a middleware platform such as simplicity, independence of applications from middleware, and componentization. In their research, AOSD has offered the separation of middleware components, the separation middleware details from application domain concerns, and the configurability of middleware components and their composition.

2.4 Aspect Mining

41

Categorization of Legacy Systems Tekinerdogan and Satroglu [48] have categorized legacy systems as a part of their research on an aspectual analysis of legacy systems. According to them, there are three main criteria for categorizing legacy systems. 1. Categorization Based on Criticality This uses the business criticality as the criteria. The legacy systems that belong to this category include mission critical and replaceable legacy systems. 2. Categorization Based on Health State This uses health state criteria and compares legacy systems to living organisms. Legacy systems that belong to this category can be in any of three types of legacy systems: healthy, ill, and terminally ill. 3. Categorization Based on Accessibility This uses the accessibility as the criteria. The legacy systems that belong to this category define as either black box or white box legacy systems. Approaches for Analyzing Legacy Systems In the research literature, there are many approaches for analyzing legacy systems [48, 50]. Figure 2.21 depicts an approach taken by Tekinerdogan and Satroglu [48]. It is an approach to analyze an object-oriented legacy system for identifying and modularizing crosscutting concerns and to refractor the legacy system to an aspect-oriented version of the system. As per Fig. 2.21, the first step in the legacy system analyzing is to identify the category of the legacy system. If the type is terminally ill, then the system may be either redeveloped or dismissed. If it is maintainable and the concerns that should be enhanced are crosscutting concerns, then the aspectual refractoring is applied to maintain the system. By performing a quantitative aspect analysis, Zhang and Jacobsen [50] showed that current middleware architectures suffer due to crosscutting concerns. They used aspect-mining approaches to analyze aspects of a middleware system. Furthermore, they did an aspect-oriented refractorization of a CORBA middleware platform and compared the new design with the old one. Refractoring has significantly lowered the complexity of the architecture and the statistical data showed that the same functionality can be implemented at least by 9 percent less code, 12 methods fewer in total, and 70 instances fewer in terms of coupling with other classes. Furthermore, the observation of the response time showed that the overhead due to the refractoring was negligible. The first step in the refractoring process was to identify the primary functional decomposition of the middleware. It includes the identification of primary functionalities, primary architectural elements, and so on. The second step was to identify aspects that crosscut identified primary functionalities. Aspects can encapsulate orthogonal functionalities to the primary functionalities. Furthermore, the well-known aspects such as logging and synchronization

42


Fig. 2.21. An Approach for Analyzing Legacy Systems

are suitable candidates for possible aspects. Finally, the system was refractored using the AOP techniques.

2.5 AOP Based Software Product Line Aspect-Oriented Software Development (AOSD) is a paradigm that has a direct relationship to the SPL because one of its main objective is to separate crosscutting concerns to promote flexibility and configurability. These two goals are also vital for constructing a SPL. In addition, the AOSD can improve the way in which software is modularized. Alves, Dantas, and Borba [51] have presented an approach using AOP to implement the feature variability. It is a stepwise process. 1. Designing Product Line Architecture In this step, the main activity is designing a flexible architecture focusing on mandatory features. Architectural design patterns can provide inputs to make a flexible yet simple architecture. 2. Designing Variations using Aspects This involves designing both joint point models by identifying execution points of an application to be crossed cut and aspects by encapsulating

2.6 Related Work

43

variable features. The use of design patterns in this step makes aspects are adaptable. 3. Composing Aspects of a Product and Business Classes using AOP Weavers This step uses AOP weavers to generate code by composing the systems base functionalities with aspects according to the product specifications. 4. Generating Versions of a Product This final step compiles generated codes and then packages applications. The above process is a generic process that can be used by many product line approaches, and influences the ESB product line approach presented in this thesis. Harvey and Suesaowaluk [52] have presented an aspect-oriented product line framework to support the development of a SPL of web applications. That paper provides a framework that uses the AOSD in order to manage and trace the variability of products at each stage of a life cycle of the SPL. Figure 2.22 depicts that approach. As per Fig. 2.22, the main activities in the framework are domain engineering and application engineering and their mapping with the Software Engineering Institutes activities. Domain engineering includes activities such as identifying the commonality and variability of the product line, whereas application engineering includes building of the applications of the product line. Voelter and Groher [53] have described an approach that facilitates the variability implementation, management, and variability tracing from architectural models. It used a DSL for describing the variability, a component based architecture for modeling components and the AOP for implementing the variability.

2.6 Related Work 2.6.1 Research on AOP and ESB A little research attempted to bring the concepts of the AOP into the ESB. Ermagan, Kruger, and Menarini [54] have discussed an aspect oriented modeling approach to define routing in ESB. It leveraged the rich services and Message Sequence Charts (MSC) to control routing capabilities of an ESB in an aspect oriented way. MSC defines interactions between components, which communicate with each other through a message exchanging. It has a formal graphical notation somewhat similar to the UML sequence diagram. That research addressed crosscutting concerns by modifying the message flow through a router-interceptor layer. At runtime, the interceptor creates an implementation model based on an aspect MSC and observes the communication. If the aspect MSC is applicable, the interceptor modifies the behavior accordingly to the aspect.

44


Fig. 2.22. An Aspect-Oriented Product Line Framework

Bai and Fitch [55] have developed an ESB framework for the discovery and delivery of hydrological data to users. That research used AOP-based approach to implement functions such as logging and exception management. By using AOP architecture, these logging and exception management components could traverse all business logic (data modules) providing an elegant solution to these cross cutting concerns. 2.6.2 AOP Frameworks This section explores two industrial-strength AOP frameworks that provide integrated AOP support. AspectJ [56] is an aspect-oriented extension to the Java programming language and is an internal DSL. As it is based on the Java language, it gives more benefits to anyone has already familiarized with Java. AspectJ includes

2.6 Related Work

45

constructs to define the point-cuts and advices. Furthermore, it includes concepts related with the aspect precedence, association, and inheritance. Spring [37] provides a rich support for the AOP in its AOP module, which serves as a basis for developing new aspects for any spring-enabled applications. The springs support for the AOP can be identified in four ways: proxybased AOP, AspectJ annotation based aspects, pure POJO aspects, and injected AspectJ aspects. The AOP framework presented in this research uses the proxy-based AOP in additions to a few newer methodologies. Spring provides implementations of some aspects including caching, exception handling, logging, transaction, retry, and parameter validation. Spring AOP language syntax is an XML-based where the point-cuts and advices are XML tags. The point-cut model is similar to the AspectJ. To use the springs AOP in an ESB, the components of the ESB should be spring components (i.e. spring beans). Therefore, the qualities such as reliability, performance offered by the ESB architecture cannot be leveraged. With our approach, most ESB architectures and existing ESB components can be used as is, as we effectively transform a generic ESB service into a component of the target ESB. Furthermore, our aspect weaver is based on the architectural styles, which are suitable for the ESB that uses the aspects. Therefore, our approach can preserve the qualities ESB architecture provides, or it further can enhance those qualities. 2.6.3 Component Frameworks Microsoft Enterprise Library (MEL) [57] has attempted to capture enterprise wide concerns to enable reuse of them within a wide range of applications. MEL consists of designs and implementations of widely used concerns in the enterprise applications including logging, caching, security, validation, police injection, data access, and exception handling. The goals of the MEL include consistency, extensibility, ease of use and composability. The aspect library developed in this research project has drawn many best practices and principles as well as goals, from the work of MEL. The main difference between our work and the MEL is that our focus is to develop a generic ESB service and transparently transform the generic ESB service to the components of the system, which requires the ESB service. This allows us to obtain the qualities that the target systems architecture provides. An interesting approach to obtain the advantages of different ESB architectures is the embedding an implementation of an ESB architecture as a component of another ESB. Petals ESB [58], that is a JBI based ESB, has embedded a SCA service engine as a JBI service component. Our approach is different from that work as we attempted to develop generic ESB services, which can be effectively adapted into components of most ESB architectures such as SCA, JBI, MQM, etc. When implementing an integration solution, our approach offers a higher flexibility to a software architect for selecting an appropriate ESB and changing the selected ESB as needed without undue cost

46


and time as the ESB services developed for a one ESB is completely reusable in another ESB. Currently, there is a trend to build systems based on OSGI (Open Services Gateway Initiative) [59], which is a standard for modular components. As per our knowledge, there are no multiple product lines, which are based on OSGI. However, we believe that by developing reusable functionalities as OSGI components and with a suitable approach to reuse the OSGI components in different architectures, an OSGI based platform can be used to formulate multiple product lines. However, we see a major disadvantage with an OSGI based approach the tight coupling to the OSGI. If it is needed to replace the OSGI with some other component model, then, the modification required will be high. Our approach to structure aspects is not coupled to a particular component model and provides the flexibility to select the component model suited to a particular product. We believe that with a capability to create OSGI services programmatically, the aspect weaver can use the OSGI to structure aspects. 2.6.4 Multiple Product Lines Aoyama, Watanabe, Nishio, and Moriwaki [60] have discussed a framework for multiple product lines of e-government systems. Their approach is based on a common framework, which is capable of creating specialized product frameworks such as a framework for water management product line, a framework for dam monitoring product line, etc. In their approach, the first step is to identify reusable scenarios across a diverse customer base and to implement the reusable scenarios in the common framework. Secondly, the frameworks customized for different customer base is derived from the common framework. In our approach, there is a single platform. However, we can create separate platforms for each different customer domain or different product as needed by reusing the common platform. Wijnstra [61] has discussed the experiences with the development of a platform in the medical imaging domain. The platform was based on three main ingredients components, interfaces, and information models. Components have interfaces, which uses an information model to specify the data exchange over interfaces. These concepts are somewhat analogues to the concepts used in the aspect design. Aspects only expose a single interface and use the data access model to exchange the data. In our approach, the interfaces of components (aspects) do not change and the data access model can be changed transparently using the extensibility mechanism provided through Interceptors.

2.7 Summary In this chapter, we discussed the research literature relevant to this our research. We described ESB (Enterprise Service Bus) highlighting its architec-

2.7 Summary

47

ture and the technologies for implementing it. The commonality and variability in the architectures and the features of existing ESB products was the key motivation for the research presented in this book. We also discussed AOP (Aspect Oriented Programming) including aspect weaving, aspect mining, AOP framework architectures, and aspectual refractoring. Moreover, we presented three AOP based software product lines. We also presented the domain analyses of ten aspects related to an ESB. Finally, we explored the related work through four directions: research on AOP and ESB, AOP frameworks, component frameworks, and multiple product lines. The next chapter is to present and discuss the design and implementation of our research project.

3 An Aspect-Oriented Platform for Multiple ESB Product Lines

Good design goes to heaven; bad design goes everywhere. – Mieke Gerritzen Everything is designed. Few things are designed well. – Brian Reed Nowadays, enterprises are adopting information technology (IT) to automate their business processes and simplify their operational activities. A typical business process composes discrete business functions provided by multiple applications. An adaptable and flexible integration of these applications is crucial to execute the business process efficiently, and an enterprise service bus (ESB) is to provide robust solutions for application integration. The ESB market comprises diverse ESB products and customers. The capability to produce each ESB variation and individualized products can potentially make opportunities to dominate the ESB market. A software product line (SPL) is an approach that can provide such a capability. Traditional SPL approaches usually develop products with the same architecture and provide a systematic reuse only within a single product family. In order to develop different product families, a suitable approach is the multiple product lines. A platform for multiple product lines should provide a systematic reuse within multiple product families and be capable of producing products with different architectures reusing the same set of core assets. This chapter discusses the design and implementation of a platform for multiple product lines of ESB. Three vital ingredients of a platform are a component library, a component assembler, and a component and composition definition language. We leveraged the principles of AOP to develop our platform. In our platform, a component is an aspect, and the aspect weaver is the component assembler. Aspect and Composition Definition Language (ACDL) serves as the component and composition definition language. In our discussion of the platform, first, we outline the relationship between AOP and our platform. Secondly, we define the assets that are reusable across

50


different architecture, and present an asset development methodology. Finally, we present the aspect library, the aspect weaver, and the ACDL.

3.1 Applying Aspect Oriented Programming As per the analysis presented in Sect. 1.1, different ESB products offer a slew of similar functionalities but the source codes of implementations of those are different and kept separately in each product. This situation is a kind of scattering and AOP is suitable to address that. In other words, we used the concepts of AOP to modularize the functionalities that crosscut different ESB products. Aspects encapsulate ESB services such as security, logging, cache, HTTP (Hypertext Transport Protocol) transport service, etc. Those are developed as autonomous software elements and can be adapted to the components of the different ESB products. To use the functionalities offered by the aspects within a particular ESB product, we developed an aspect weaver, which can structure the aspects based on the architecture styles that are suitable for the products, which require the aspects. We believe that our approach for the aspect weaving is mostly suitable for the middleware products with a component model to assemble the components of them. The composition is based on the AOP advices: after, around, and before. AOP advices are defined using aspect and composition definition language (ACDL) as a part of points-cuts. Aspects weaved around ESB components based on the AOP advices, and the aspect weaving transparently modifies the component model of the target ESB. Although, currently, the aspect weaving is done at ESB startup, by modifying the component model at runtime, we can perform it at runtime. Throughput this chapter, we use the term aspect, ESB service, and core asset synonymously.

3.2 Multi-Architectures Reusable Asset A core asset for multiple product lines should be reusable in different architectures. We coin the term Multi-Architectures Reusable Asset for such a core asset. An aspect is such an asset as it encapsulates the functionalities that crosscut different ESB products. First, this section provides seven essential requirements for a Multi-Architectures Reusable Asset. The requirements are selected so that an asset can evolve independently, and can be reused as-is in different architectures with the required quality attributes. Secondly, we present a novel approach for developing Multi-Architectures Reusable Asset including requirement gathering, design, and implementation.

3.2 Multi-Architectures Reusable Asset

51

3.2.1 Characteristics •

•

•

•

•

•

Autonomous It should be able to reuse an aspect as-is in different architectures. An aspect should be well-defined, self-contained, and does not depend on the context or state of other functional components. In this perspective, the aspect is analogous to a service in SOA (Service Oriented Architecture). Modifiability As an aspect is to be used by many different products, a functional change introduced to the aspect for supporting requirements of one or more products, cannot affect most products in the product lines. Modifiability can make the adding new product lines and modifying existing product lines transparent. The autonomy of an asset can enhance the modifiability of it. Adaptable to Multi-Architectures As a core asset is possibly used in multiple different systems, the effective adaptation of an asset to different architectures is crucial. Composable with Multi-Architectures An ESB is a component based middleware system and has a component model to assemble ESB services. The architecture of an ESB determines the component model. As an aspect is to be used by different ESB architectures, the flexibility to assemble aspects based on various architectures is inevitable. Quality Attributes Configurable The multiple product lines approach would not only be successful if an aspect cannot provide quality attributes required by different products. It is needed to support quality attributes such as performance, scalability, etc., required by different products in different granularity and mix such as low performance - high scalability, high performance- high reliability, etc. The requirement is to have a design that can configure to achieve the desired qualities in appropriate levels. Supporting Variation Points Core assets in the product line should be designed with variation points, which are the places that can be tailored to a particular product in preplanned ways.

Next sub sections discuss the essential design decisions taken to support above six requirements. 3.2.2 Design and Implementation Strategies Data Access Model The primary factor, which decides the reusability of an aspect in different products, is the coupling between the aspect implementation and the products. By eliminating this coupling, aspect can be made reusable in any product

52


variation. For this purpose, we analyzed the behavior of an aspect in a set of ESBs. As per our analysis, an aspect is a data processor and the data is provided as a message. It takes an input data from the message, performs operations such as transformation, encryption of that data, and produces some output data. A data access model can make as aspects autonomous, which only depend on the data access model for providing their services. We identified two categories of data configuration and runtime. For the security aspect, the configuration information includes the key store information, cryptographic operation, etc., whereas the runtime data include the data on which the cryptographic operation applies. The ACDL serves as a means of providing configuration information required by an aspect. To provide runtime data, we developed a data access layer and designed each aspect to use only the data access layer for implementing its functionality. The data access layer is based on the two concepts: Message and Interceptors. Message. Message is to exchange the data between aspects and to make aspects loosely coupled. It leverages the Message [15] pattern, which provides a means of exchanging pieces of information across the network without introducing dependencies on concrete component types and their interfaces. Figure 3.1 shows a fragment of Message interface.

Fig. 3.1. Message Interface

MessageHeaderSet contains control information such as the operation of the aspect that should apply to the data in the message. Most control information is analogues to the configuration information. The payload (data) is in MessageBody. Typically, a Command encapsulates a retryable operation such as database access. It is used to exchange internal requests among aspects. For example, to retry for failures in database access, the persistence aspect can send a database access operation as a command to the error handler aspect.

3.2 Multi-Architectures Reusable Asset

53

Command allowed us to achieve a desired level of separation of concerns and reuse. Interceptors. Message only provides generic functionalities such as accessing message content, control headers. Interceptors are to extend the functionality offered by the message without introducing the coupling between the message and a particular aspect. The interceptor implementation uses the Extension Interface [15] design pattern to achieve the required adaptability and extensibility for developing products specific aspects without changing the API of the data access layer. The access of the special information in the message such as URL parameters, users IP, is an example for the usage of interceptors. We further extended the interceptors to provide a way to obtain the information from the system environment that uses aspects, and systems base components. Figure 3.2 depicts the design of the interceptors.

Fig. 3.2. Interceptors

Interceptor is the base class for any interceptor, and it provides a method to access each extension interceptor. ComponentInterceptor intercepts the systems base component to get information such as names and expected return types of the methods of the systems base component. EnvironmentInterceptor intercepts the operating environment to provide functionalities such as lookup and execute systems base components and to get information such as the systems identity and trust key stores. The data access model provides the autonomy and a considerable level of modifiability and adaptability for an aspect. Aspect Development Methodology We believe that modifiability is a key quality attribute that a core asset should support. As in multiple product lines approach, many different products reuse a particular core asset, the modification to that core asset should be made without affecting other core assets and most products in the product lines. Typically, modifications include changes in both functionality and other quality attributes such as performance, reliability, etc. For achieving this level of modifiability, our design decision was to capture requirements for a minimal yet complete behavior of an aspect, and to encapsulate all additional functional requirements and quality requirements as extensibility points. We

54


formulated a procedure to implement our design decisions and present it following. 1. Identifying Intuitive Requirement By Intuitive Requirement, we mean the high-level requirements of a particular aspect that obviously can be identified as the minimal requirements to provide a useful service for at least one product. The Intuitive Requirement represents the simplest yet a complete behavior of an aspect. It captures the mandatory features of an aspect. More precisely, it captures invariant commonalities that must be in any variation of a particular aspect. 2. Drawing the Feature Model A feature model can be used to present the commonality and variability of an aspect. It specifies the requirements for an aspect concisely. When creating the feature model for an aspect, the first step is to identify the mandatory features based on the Intuitive Requirement. Secondly, with a comprehensive domain analysis for the aspect such as the analyses presented in Sect. 2.2, we complete the feature model. The aspect design process uses feature models as appropriate to identify variation points. An aspect design should support the realization of the feature model of the aspect. 3. Designing the Aspect to Support the Intuitive Requirement Based on the Intuitive Requirement, we formulate the initial design for an aspect. To achieve a desired level of modifiability for the aspect, we adhered to the principles of information hiding and separation of concerns. As the Intuitive Requirement is simple and considerably stable, the initial design of an aspect is simple and sustainable. 4. Incorporating Additional Requirements into the Design as Extensibility Points Intuitive Requirement represents the minimum requirements to provide a complete behavior of an aspect. In the multiple product lines approach, we believe that there should be a suitable flexibility to formulate a new product line without affecting other existing product lines. For this purpose, we decided to decouple the minimum requirements from additional requirements, and to incorporate additional requirements into the design as extensibility points. This has allowed us to achieve an adequate level of modifiability for an aspect. After adding support for a new requirement, we always reengineer the design to trace the Intuitive Requirement as the change in the Intuitive Requirement indicates that an unsuitable modification to the design has been done. 5. Incorporating Quality Attributes Another challenge in designing a core asset for a platform for multiple product lines is the supporting quality attributes requirements of different products. For example, an ESB designed for supporting higher reliability may require aspects designed for supporting higher reliability; An

3.3 Aspect Library

55

ESB designed for supporting high performance may require aspects designed for supporting high performance. The conflicts in quality attribute requirements for an aspect are obvious. We believe that the quality attributes and functionalities are orthogonal and the design decisions taken for implementing functionality will determine the relative level of quality [8]. Based on that thought, we decided to support quality attributes as extensibility points in the initial design resulted from the above four steps. In other words, we decided to refine the initial design based on a quality attribute analysis. As a particular core asset has to support quality requirements of many products, we defined a compressive set of quality attributes based on the work by Bass, Clements, and Kaman [8]. The procedure for refining the initial design can be intuitively divided into two steps. The first step is to select a set of applicable qualities from the complete quality attributes list. Secondly, for each quality attribute in the selected list, we determine tactics that can be used to support that quality with a wide range of levels such as low, high, etc.

3.3 Aspect Library The aspect library is a software library that attempts to implement aspects as reusable and adaptable components. It consists of eight aspects namely log, crypto, caching, load balance, exception handling, monitoring, persistence, and proxy. Aspects are autonomous entries and do not depend on any other aspects and can be composed using AOP techniques. More precisely, an aspect is a Multi-Architectures Reusable Asset. Each aspect has a feature model, which is formulated prior to construct the design. However, we here do not present the feature models of the aspects as we discuss them in Chap. 4. On the other hand, to understand the design and implementation of an aspect, the feature models are not essential. 3.3.1 Design Goals Microsoft Enterprise Library (MEL) [57] strongly affects our work and four goals of the aspect library are similar to the goals of the MEL, which are consistency, extensibility, ease of use, and integration. •

•

Consistency The designs of the aspects should preserve conceptual integrity. The configurations of all aspects should be consistent. Extensibility Each aspects implementation follows the design principle program to an interface, not an implementation. It defines extensibility points in terms of interfaces and uses the Factory [17] pattern to find and create the implementations of those interfaces.

56

•

•

•


Ease of Use An aspect is configurable and has a configuration defined in the ACDL. The textual ACDL featuring a DSL approach is easy to use and remind for human. Integration An aspect can integrate with other aspects seamlessly, and the integration is guided by AOP concepts and is done by aspect weaver. AOP makes it easy to integrate aspects not only with other aspects, but also with software components from a wide range of java based software systems. Strategic Reuse of Existing Software Libraries Each aspect provides a way to integrate existing software libraries in the corresponding domain of the aspect.

3.3.2 Log Aspect Log aspect provides a wide range of common logging functions required for an enterprise-wide middleware. Section 2.2.1 explained the features of a logging component in an integration middleware, and many of them have included in the design and implementation of the log aspect. Intuitive Requirement. Logs are generated and the generated logs are transported into the destinations, which process the logs. Quality Attributes. Functionality, Security, Extensibility, Performance, and Availability As per the intuitive requirement, we selected the primary elements for the design of the log aspect as log sources that generate logs, a medium to transport the generated logs, and destinations, which process the logs. To support desired performance, we implemented the log generation as a staged process where each stage performs a filtering on the raw log records. Therefore, we selected the log filtering as an essential ingredient for the log aspect. To preserve the conceptual integrity, we designed the log records transport using the channel concept in the aspect weaver, which is discussing in Sect. 3.4.3. As log records should be presented in a format suitable to analyze, the log formatter was also incorporated into the log aspect design. Both log filtering and formatting are optional. Figure 3.3 depicts the design of the log aspect.

Fig. 3.3. The Design of the Log Aspect

3.3 Aspect Library

57

In Fig. 3.3, Logger generates log records, and then performs the filtering on the generated logs. LogSource is a destination for raw log records and routes the raw log records to log sinks through a LogMessageChannel. LogSink is a destination for raw log records, and uses log formatters to format log records before doing its operations such as saving a log record in a database. Next sections discuss the log aspect design in detail. Raw Log Record Generation. The log aspect creates log records in a way that minimizes the overhead. First, it creates a LogEntryHeader using a factory. A log header consists of information such as an event id, an event source, a category and so on. After creating a header, the logger applies the log filtering using the registered log filters and a filtering strategy to detect the logging action. The result of this indicates to either continue or abort the logging. Only if the result indicates to continue, the logger creates a LogEntryBody, which contains the log message. Thereafter the log filtering is applied again to detect the logging action base on the content of the log message. The log message can be in any form such as a message payload or some other event information generated by another aspect. Log Filtering. Log filtering performs based on either the header or the body of a log record. This approach reduces overhead on the run-time performance as discussed in the above section. It is possible to have many log filters in a single log aspect. If so, a filtering strategy is used to decide the result of log filtering. There are two filtering strategies namely PassAll and PassOne. PassAll allows the logging only if all filters allow so. PassOne allows the logging if any filter allows so. There are seven filters in the log aspect implementation. 1. Log Enabled - Enables or disables logging 2. Priority Based - Uses log priority 3. Category Based - Uses log categories 4. IP Based - Uses the IP address of the client 5. Domain Name Based - Uses the domain name of the client 6. XPath Based - Evaluates an XPath on the message. If it reruns true, only then allows the logging 7. Regex Based - Using an XPath, takes a text (string) from the message and then validates it against a regular expression Log Source and Log Message Channel. Log sources decouple the generation of raw log records from the persistence of formatted log records. A log source is a destination of raw log records and routes these raw log records to log sinks

58


through a log message channel. LogMessageChannel, which decouples the log source from the log sinks, can be implemented using various technologies such as the message-oriented middleware. The log aspect implementation provides a method invocation based channel, and a queue-based channel that allows the passive logging to minimize the logging overhead. Log Sinks. Log sinks are the destinations for the log records, and uses log formatters to format the log records before doing its operation. The concept of the log sink allows integrating existing logger libraries such as Log4J [62]. There are three types of the log sinks in the log aspect. 1. Console Log Sink - Print messages on the console 2. Log4J Log Sink - Use appenders of the Log4j 3. Message Log Sink - Puts on the current message in the flow An appender of the Log4j is an output destination, similar to a log sink. Log4j has different appenders including JDBC (Java Database Connectivity), JMS (Java Message Service), file system, SMTP (Simple Mail Transfer Protocol), and so on. The message log sinks enable to use formatted log messages by other aspects to implement scenarios such as a secure logging and a sending of log records to remote log analyzers. Log Formatters. Log formatter formats a raw log record into an application specific format. The log aspect implementation has three types of formatters. 1. Text Formatter - Formats a log record to a text entry 2. SOAP Formatter - Creates a SOAP (Simple Object Access Protocol) message from a log record 3. XML Formatter - Creates an XML (Extensible Markup Language) from a log record Both SOAP and XML formatters are useful when the log records are sent to remote log analyzers, which are physically separated and can be connected using application level protocols such as HTTP. 3.3.3 Error Handling Aspect Error handling aspect provides the exception management functionality, which an integration middleware requires.

3.3 Aspect Library

59

Intuitive Requirement. An error can occur in any layer such as communication, data access. An error handling should be based on the category of the error and the ultimate receiver of the error, which can be an end-user, another aspect, or an ESB component. Quality Attributes. Functionality, Security, Extensibility, Performance, Availability, and Fault Tolerance As per the first requirement, the errors are diverse and can occur in any layer such as communication, data access. In order to simplify the types of errors, we introduce the retryable errors and non-retryable error. For retryable errors, we retry to enhance the fault tolerance of the system. As the identification of the cause for a failure at later possibly requires the details of the error, we introduced the error logging. If the ultimate receivers of an error are end-users, then the technical details of the error should be replaced with the business content to indicate a business problem. To propagate an error to another layer, the policy is to create a new error and wraps the original error within it. The design decision to capture various error handling requirements such as logging, wrapping, etc., is to use abstractions of a policy and an error hander, which is responsible for performing the error handling, based on the policy. Figure 3.4 depicts the design of the error handling aspect.

Fig. 3.4. The Design of the Exception Handling Aspect

Each error handler has a policy defining the meta-data needed during the error handling operation. The policy also provides a factory method for creating the instances of the corresponding error handler. There are four types of error handlers: 1. Replace Error Handler Replaces the content of the original exception with a custom content 2. Wrap Error Handler Creates a new exception and wraps the original exceptions within it 3. Logging Error Handler Logs the information of the original exception 4. Retryable Error Handler In an integration middleware, both the components and the communication infrastructure can have transient failures and the retrying on those failures enhances the fault tolerance of the system. For the failures in both the components and the communication infrastructure, the logic of retrying should be consistent. This exception handling strategy retries for retryable exceptions. The implementation uses Command [17] pattern to

60


encapsulate the retryable operation and Retryer [63] pattern to encapsulate the retrying logic to make the retrying consistent with any failure. Any component can create an implementation of the RetryableErrorEntry and an implementation of the Command encapsulating a retryable operation. 3.3.4 Persistence Aspect Persistence aspect provides common data access functionality such as reading data, saving data. Although, the persistence aspect implementation currently only supports relational databases, it is possible to add new database platforms and new database technologies such as an XML database and an object-oriented database. Intuitive Requirement. An input data is generated and the generated data is transported to the destinations where the data are saved. An output data can be retrieved from the destinations and the retrieved data can be transported. Quality Attributes. Functionality, Extensibility, Performance, Availability, Security, and Fault Tolerance As per the intuitive requirement, we selected the primary elements for the design of the persistence aspect as the input manager that generates the inputs for data access operations, a medium to transport the generated inputs, and destinations, which perform the data access operations using the received inputs. We have identified the main extensibility point as the multiple database platforms and database technology such as XML, Object Oriented and rational databases. In order to achieve a better performance, an asynchronous model for persistence was introduced by decoupling the input generator and the destinations through the same channel concept used in both the log aspect and the aspect weaver. The security requirements were supported by using the security aspect and were achieved only through the aspect composition and there is no direct dependency to the security aspect. Fault tolerance is required when a data access operation is failed due to retryable errors and was supported using Retryer [63] design pattern and the error handling aspect. Figure 3.5 depicts the design of the persistence aspect.

Fig. 3.5. The Design of the Persistence Aspect

DataAccessor provides the access to the underlying persistence system. Input encapsulates the values of the parameters used in database queries. It decouples the data type information such as SQL types from the data, and

3.3 Aspect Library

61

InputAdaper converts the data to the target data types such as SQL query parameters. The purpose of Output and OutputAdapter is similar to the input adapting except it deals with the results of the data access operations. Next sections discuss the design of the persistence aspect in detail. Data Access. The data access component implements the DataAccessor [63] pattern, which is to decouple the data access logic from the physical data access details. AO4ESB provides a Java Database Connectivity (JDBC) based implementation and an experimental Java Data Object (JDO) based implementation. Inputs Adapting. Each data access operation needs the data, which typically is given as the parameters of the operation. The types of the data depend on the underlying database system. For example, the data types in JDBC differ from the data types used in JDO. On the other hand, if the persistence system uses XML or any other technology, this difference will be significant. A solution to deal with the differences in data types is to decouple the data type information from the data and exposing a logical entity representing the data. The input adapter is to provide it. The persistence aspect consists of a JDBC input adapter that locates and converts data to SQL query parameters, according to the valid SQL types. InputManager is responsible for that task and uses different input adapters appropriately. Input Transport Channel and Input Sinks. InputTransportChannel, which decouples the input manager from the input sinks, can be implemented using technologies such as MOM. The persistence aspect implementation provides a method invocation based channel, and a queue-based channel that supports the passive persistence to minimize the database access overhead. Input sinks receive the inputs from an InputTransportChannel and use those inputs to perform data access operations. There are two types of input sinks one for reading the data from the database and other for updating the database. Outputs Adapting. The purpose of the output adapting is similar to the input adapting except it deals with the results of the data access operations. OutputManager is responsible for this task and used different output adapters as needed. 3.3.5 Cache Aspect An enterprise wide distributed system uses caching as a mechanism to improve performance, achieve high scalability and availability. The required features for a cache component were discussed in the Sect. 2.2.3 and the objective of the cache aspect is to provide them. Intuitive Requirement. Caching is applicable in any layer such as communication, data access. A cache should be loaded with the data and applications requests should be served from the cache. The cache coherence should be preserved.

62


Quality Attributes. Functionality, Security, Extensibility, Availability, Reliability, and Performance As per the intuitive requirement, a cache should be populated with data. Therefore, both the cache and cache loader were selected as two primary elements of the cache aspect. As the caching is applicable in any layer such as communication, data access, the cache should have the capability to keep different data types. For that purpose, we introduced the cache entry. The cache coherence is related with both the cache loading and cache controlling mechanisms, which involve the removing of invalid cache items from the cache. We selected a policy-based cache controlling where the policy specifies the cache controlling strategy such as least recently used (LRU). Typically, a cache controller requires information such as the last access time of a cache entry. Therefore, we introduced observers for cache and cache entry. To achieve a higher reliability and availability, the cache should have backup stores to keep the cached data, and we selected cache storages as the abstraction to encapsulate the backup stores. Figure 3.6 depicts the design of the cache aspect.

Fig. 3.6. The Design of the Cache Aspect

Next sections discuss the design of the cache aspect in detail. Structure of the Cache. CacheAccessor [63] pattern is used to provide the access to the cache. It decouples the caching logic from the data model and data access details to make a consistent, reusable cache for all data types and database entities. The default cache implementation is a cache backed by an in-memory storage. Furthermore, it provides an Ehcache-based cache implementation. Ehcache [64] is an open source distributed caching system with functionalities such as disk-based caching, cache replication. The Ehcache integration brings those functionalities into the cache aspect. CacheListener and CacheEntryListener are to observe the cache and cache entries respectively, and are useful for implementing cache controllers, cache replicators, cache monitors and so on. Cache Controlling. The controlling of a cache involves the removing of invalid cache items and the flushing of the cache as appropriate. A background

3.3 Aspect Library

63

task performs the cache control operation to reduce the effect on the run-time performance. The implementation uses a policy-based approach based on the CacheCollector [63] pattern. Each policy provides a new cache control strategy and a factory method to create the corresponding cache controller. The policies supported by the current implementation are: 1. Fixed Expiration Entries expire after being in the cache for a fixed time interval. 2. Inactive Expiration Entries expire after not having been accessed for a fixed time interval. 3. Least Recently Used Expiration When the cache exceeds a predefined threshold, the least recently used cache entries expire. This strategy is a flushing strategy. The implementation of cache controlling has encapsulated both the cache expiration and flushing into scheduled jobs, and Quartz [65], open source job scheduling system, provides the job-scheduling capability. With the Quartz, it is possible to schedule jobs at any time to execute, even using UNIX cron expression. Using Quartz, we could schedule the cache control operations in diverse ways including fix time, periodically, repetitive indefinitely or finitely and so on. Cache Loading. Cache loading populates the cache with data. There are two approaches for the cache loading. 1. Proactive Loader This populates the cache with all data needed usually at the system startup-time. The best practice is to use an asynchronous programming model to load data on a background thread as the proactive loading can make the system start up slow. The cache aspect provides the asynchronous pull loader as the proactive loading method. The asynchronous pull loader runs periodically based on a scheduling policy and retrieves the data from the required places, and keeps those in the cache. This scheduling also leverages the capabilities of Quartz to provide a wide range of scheduling options. 2. Reactive Loader This retrieves the data using a synchronous programming model when the application requests for data and then caches it for the future requests. The cache aspect supports the reactive loading with the synchronous pull loader, which uses Demand Cache pattern [63]. 3.3.6 Monitoring Aspect Monitoring is part of system management and is carried out in order to obtain information about a system. Common monitoring activities are debugging, testing, accounting, and providing the information needed by other components in the system and the monitoring aspect designed to provide them.

64


Intuitive Requirement. It monitors the system and collects statistics. It also provides the gathered statistics to other components in the system as needed. Quality Attributes. Functionality, Extensibility, and Performance As per the intuitive requirement, we identified two categories of statistics the raw statistics, which the monitoring aspect collects from other components, and the processed statistics, which the monitoring aspect provides to other components. In order to achieve a better performance and decoupling, we have decided to use an event driven approach for both collecting the raw statistics and distributing the processed statistics. We also introduced an asynchronous model for the processing of the collected statistics. The monitoring aspect should provide the required extensibility to support system-monitoring functionalities such as debugging, testing, and accounting in the future.

Fig. 3.7. The Design of the Monitoring Aspect

In Fig. 3.7, ControlBus is to collect raw statistics from other components such as message channels and aspects. The monitoring aspect listens to the ControlBus and others publish the collected statistics to it as events. The monitoring aspect processes the received raw statistics asynchronously and publishes to MonitoringEventChanel. Other components can access to the processed statistics by subscribing to MonitoringEventChanel. Next sections discuss the design of the monitoring aspect in detail. Collecting Statistics. ControlBus is based on Control Bus [40] pattern, which provides a single point of control to manage and monitor a distributed system. The control bus is well suited to carry out messages such as configuration parameters, heartbeat, test messages, exceptions, and statistics. The control bus implementation of the monitoring aspect only carries out statistics. The control bus was implemented using Event Channel pattern. Any component can put information such as statistics as ControlBusEvent into a control bus instance and the event listeners that have registered with the control bus instance by providing instances of the ControlBusEventHandler can only receive ControlBusEvent. The implementation of the control bus in this research project, acts as a local event channel. However, it is possible to support implementations such as a queue-based channel, which can leverage an asynchronous model for propagating events to reduce the effect on the run-time performance from the system monitoring. Monitoring Aspect Event Propagating. Monitoring aspect uses the control bus to collect the statistics reported by other components. These statistics are in

3.3 Aspect Library

65

the raw format and the monitoring aspect aggregates these raw statistics and creates metrics, and thereafter sends the metrics to the components that need them. A background task, managed by a Quartz scheduler, performs the aggregation operation to minimize the effect on the run-time performance. The Event Channel pattern is used to implement the propagation of the monitoring aspects events and the implementation is similar to the control bus implementation. 3.3.7 Load Balance Aspect Load balance aspect provides the load balancing functionality required for an integration middleware. The load balancer equally distributes incoming application traffic across multiple destinations. Intuitive Requirement. Load balancer distributes incoming application traffics among multiple destinations. Upon receiving a request, the load balancer selects a destination and then forwards the received request to the selected destination. Quality Attributes. Functionality, Extensibility, Availability, and Performance Identifying a destination to forward incoming application traffics involves two steps: identifying a set of destinations with good health and selecting a single destination from the healthy destinations. We implemented the first step using a health check, which provides the capability to detect the health of destinations. In the second step, the load balancer uses a load distribution algorithm to select a destination from the healthy destinations. The loadbalancing destination is a processing pipeline consists of aspects and ESB components. This allows the destination to be any kind of components or a set of components. If a component of the pipeline can call service providers, then the load is distributed among those service providers. The identification of the destination is also attributed to the session affinity, which is the loadbalancing system’s ability to manage a user’s requests, to either a specific server or any server, depending on the session information. Based on this analysis, we have identified the mandatory features of the load balance aspect as session-less and session-aware load balancing. Figure 3.8 shows the design of the load balance aspect.

Fig. 3.8. The Design of the Load Balance Aspect

Next sections discuss the design of the load balance aspect in detail.

66


Session-less Load Balancing. Session-less load balancing provides the implementations of two main load-balancing strategies. 1. Dynamic and Adaptive Load Balancing Load distributions adjust based on the states of the destinations, determined through the health check monitoring of the destinations. The health check agent uses the monitoring aspect to get the statistics metrics belong to the destinations. There are two types of metrics: performance metric and channel metric. The performance metric provides the response time, whereas the channel metric provides the remaining capacity of the first queue-based channel of the destination pipeline. A background task performs the heath checks to minimize the overhead. The load balance aspect provides an implementation of a dynamic round robin algorithm base on these heath checks. 2. Non-Adaptive Load Balancing These algorithms do not use the heath check capability. The round robin and random algorithms belong to this category. Session-aware Load Balancing. Session-aware load balancing manages a users requests to a specific destination based on the session information. Prior to establish a session, it is necessary to determine the session identifier. The session identifier detecting logic is encapsulated into a strategy and there are six strategies in the implementation of the load balance aspect. 1. IP - Uses IP addresses of clients 2. Domain Name - Uses domain names of clients 3. Application header - Uses an application specific header 4. URL parameter - Uses a parameter in a URL 5. Basic Authentication - Uses HTTP BasicAuth header 6. Cookie - Uses cookies The cookie-based strategy is a type of the server-initiated session. SessionStore provides the session persistence. The in-memory session store is the default implementation and new implementations such as a store based on the database systems can be added. A session has a time-to-live attribute to indicate the expiry time interval. The session expiration uses both proactive and reactive strategies. The reactive strategy only checks for the expiration of the current session, whereas the proactive strategy checks and cleans all expired sessions in the session store. The proactive strategy operates as a background task.

3.3 Aspect Library

67

3.3.8 Crypto Aspect A security system should provide the confidentiality, integrity, and authentication and the cryptography provides the encryption, hashing and signing to achieve these security features. The crypto aspect uses the cryptography to achieve the security requirements of an integration middleware. Intuitive Requirement. It provides the basic cryptographic operations - the encryption, hashing and signing. It can apply these cryptographic operations to various types of data including XML and binary. Quality Attributes. Functionality, Extensibility, and Performance Although the initial implementation of the crypto aspect may not provide the XML security, it should provide the required extensibility to support the XML security in the future. The implementation uses J2SE cryptography API and its architecture. It supports the encryption, decryption, hashing, and signature.

Fig. 3.9. The Design of the Crypto Aspect

In Fig. 3.9, the encryption and decryption providers respectively encrypt and decrypt data. The crypto aspect provides both the symmetric and the asymmetric key-based encryption and decryption. The hash provider is to calculate or compare hash values, and it supports both the key-based and the non-key-based approaches. The signature provider can sign or verify data. The crypto aspect only supports the data as binary. It is useful with both the cache and logging aspects. The case study presented in Sect. 4.2.1 as part of an evaluation of the AOESB, will discuss some scenarios that use the crypto aspect to implement security requirements of some other aspects. 3.3.9 Proxy Aspect The proxy aspect can act as a proxy to a systems base component. It enables to compose the systems base components into the aspects so that the aspects can use those without referring them directly. This is an implementation of the Proxy [17] design pattern. The case study presented in Sect. 4.2.1 as part of an evaluation of the AOESB, will discuss a set of scenarios that uses the proxy aspect.

68


3.4 Aspect Weaver An aspect weaver composes aspects and the systems base components to make the final system. The aspect weaver in the AO4ESB takes a novel approach for the aspect weaving. We divided the discussion of the aspect weaver into two main sub sections: aspect adaptation and aspect composition. Motivating Example. Our discussion of the aspect assembler flows through two sections: aspect adaptation and aspect composition. It uses a simple example shown in Fig. 3.10 as needed.

Fig. 3.10. Secure Logger Example

3.4.1 Design Goals •

•

The aspect weaving must be suited for the ESB that is going to use the aspects. An ESB is a component-based middleware, which uses a component model to structure the ESB components. Typically, the ESB architecture determines the component model of a particular ESB. We believe that the runtime of a component-based system should comprise the components assembled according to the component model of it. Therefore, the aspect weaving should be able to produce the final system as if the final system is built using the native ESB components. The aspect weaving should be transparent. The architecture of a software system defines components and the relationships among them. The architecture would be preserved only if the syntaxes and semantics of the components and relationships are not changed, and the transparent aspect weaving allows achieving it.

3.4.2 Aspect Adaptation A component to be used in a particular architecture, it should be a type of components that architecture expects. In multiple product lines, products having different architectures can reuse a particular aspect. For example, JBI

3.4 Aspect Weaver

69

architecture needs JBI components and SCA architecture needs SCA components. Therefore, the requirement is to transform transparently an aspect in the aspect library into a component of the product that is going to use the aspect. For this purpose, we introduced an aspect adaptation technique, which is based on the three concepts: Data Access Layer, Skeleton Component, and Proxy. In Sect. 3.2, we discussed the data access layer (model), which is designed to make aspects autonomous. Skeleton Component A skeleton component implements the interfaces mandated by the target product architecture but does nothing in the implementation. Typically, an ideal skeleton component has empty functions but in practice, it may have internal or generic functions that are mandated by the architecture. Particular product variation only needs a single skeleton component. JBI skeleton component for a JBI based ESB; SCA skeleton component for a SCA based ESB and so on. A skeleton component is a type of joint point, which is an AOP construct, and aspects are weaved around it. To be a joint point, it should be addressable. This can be easily done using the configuration of a product. Skeleton component development for Synapse ESB is described in next paragraph. Mediator is the ESB service in Synapse. The skeleton component for Synapse is a mediator. It needs two attributes namely the name and type and the methods to access those attributes. All other methods are ideally empty. Figure 3.11 shows the skeleton component for synapse. In Fig. 3.11, the mediate method of the skeleton component provides the access to the service the mediator offers. Synapse configuration is an XML and each mediator should specify a XML tag name. We named our skeleton component as component. For the example presented in Fig. 3.10, the skeleton component configuration is shown in Fig. 3.12. As per Fig. 3.12, the configuration of the skeleton component can define an ESB service in an abstract and concise manner. For example, in the above configuration, the secure logging service is defined without concrete details. This way, the instances of the skeleton component can be used to define every ESB service involved in an integration solution. In other words, an integration solution can be modeled using the skeleton component. This would be the same for most products. Proxy Proxy is to transform an instance of a skeleton component into a functional component, which provides a functionality such as security, logging. Proxy provides the same interfaces as the skeleton component and the logic inside the proxy is merely the execution of the aspect implementations. Figure 3.13 shows a proxy for Synapse.

70


Fig. 3.11. Synapse Skeleton Component

Fig. 3.12. The Skeleton Component Configuration for the Secure Logger

Both preProcessor and postProcessor are a set of aspects structured according to a particular architecture and the procedure for creating those will discuss in Sect. 3.4.3. In Fig. 3.13, the mediator instance can be either a synapse native component or a skeleton component. When an aspect is weaved into a skeleton component or a native functional component, the adaptation process creates a proxy with references to the aspect chains (preProcessor and postProcessor) and replaces the skeleton component or the native functional component with the created proxy. The proxy creation method can be provided through an Interceptor that was discussed in Sect. 3.2.1. Discussion The aspect adaption is transparent as the proxy and the skeleton component implement the same interfaces. It is also highly effective, as only a single proxy implementation and an implementation of the data access layer are needed to adapt any aspect in the aspect library for a particular architecture. The

3.4 Aspect Weaver

71

Fig. 3.13. Synapse Proxy

adapted aspects can be composed using the product architecture. The cost associated with the adaption technique is mainly attributed to the implementation of the data access layer, especially the message. However, the effect on the performance can be limited to one additional method call by implementing the message as a wrapper for the context object being passed between the components of the product that uses aspects. For Synapse, it is a wrapper around synapses MessageContext. For a JBI based ESB, it is a wrapper around the MessageExchange, which is the context being passed between JBI components. 3.4.3 Aspect Composition Aspect composition is done by the aspect weaver and is divided into two categories: aspects-to-aspects and aspects-to-skeleton components. The composition is based on the AOP advices: after, around, and before. AOP advices are defined using aspect and composition definition language (ACDL) as a part of points-cuts that specify the join points, which can be used to locate aspects and the components of the system that uses aspects. Aspects weaved around the components based on AOP advices. Aspects to Aspects Composition Aspects-to-aspects composition is a merely structuring aspects based on a component model which assembles aspects according to a particular architecture. A single aspect provides a basic functionality and most often, a particular

72


solution requires a complex functionality. For example, a log aspect is a basic functionality, whereas a secure logging service is a complex functionality, which is a composition of log and security aspects. A complex functionality produced by the aspect weaver must provide at least the same software quality attributes that would be provided if aspects were the components of the product. Therefore, we decided to decouple the AOP specific functionality and the component model that structures aspects. Aspects-to-aspects composition can be broadly divided into two steps. The first step is to read the ACDL file and build aspects based on the configuration information given in the ACDL. Then, based on the point-cut definitions, an instance of the AspectChainPair is created. AspectChainPair consists of two AspectChain instances namely pre-processor and post-processor. AspectChain is merely a list of aspect instances. The pre-processor aspect chain is built based on the before advice and the post-processor aspect chain is built based on the after advice. The around advice populate both preprocessor and post-processor with instances of aspects. The second step is to structure the aspects in the AspectChainPair based on a given component model implementation. We encapsulate the component model into an interface AspectObjectModel, which is shown in Fig. 3.14. The implementation of the AspectObjectModel can be configured, or given as an object at runtime.

Fig. 3.14. AspectObjectModel Interface

The return type of the build method of AspectObjectModel can be diverse. For example, it can be just a sequence of aspects, or it may represent some structure of the components of the product that uses aspects. In the second case, aspects have to be transformed into the required component type using aspect adaption technique discussed in Sect. 3.4.2. We have developed a component model to be used by many different products to structure aspects. It is based on the Pipe and Filter architectural pattern [15], which is suitable for a system that is doing a staged data stream processing where each stage consists of components performing operations such as transforming data. Hohpe and Woolf [40] have discussed the significance of the Pipe and Filter pattern as a fundamental architectural style for an EAI middleware such as message brokers, ESB, etc. With the aspect weaver that uses the component model based on the Pipe and Filters, the aspects-toaspects composition is merely a process of creating an aspect pipeline, which

3.4 Aspect Weaver

73

consists of filter units and channels. Filter unit is the filter component of the Pipe and Filters pattern, whereas channel is the pipe. Figure 3.15 depicts a pipeline.

Fig. 3.15. A Pipeline

In Fig. 3.15, a FilterUnit uses the in-channel to receive input data from the previous FilterUnit. After processing the input data, it produces and transmits output data to the subsequent FilterUnit through the out-channel. The main component of the filter unit is the processor, which encapsulates a processing step. An aspect is a processor. A channel can be a method invocation, an in-memory queue, or a sophisticated message channel. A message channel can provide language, platform, and location independence between the filters. The obvious choices for the message channels are message-oriented communication systems such as JMS, IBM MQ, and Web Service infrastructures. Another candidate is in-memory queues. A queue-based channel can decompose an application into stages, which in turn enable event-driven, non-blocking processing. AO4ESB provides a method invocation based channel and a queue-based channel. Considering the relationship between channels and processors, a cannel implementation can be a point-to-point or publish-subscribe. Aspects to Skeleton Component Composition Different products have different architectures to structure its components, and different configuration languages to define the components and their composition. Typically, based on the configuration information, the components are assembled to form a particular object model. Ideally, an object model consists only with instances of the skeleton component and product-specific components (native components). Aspects should be weaved to the skeleton components or native components to use the functionalities offered by the aspects. Aspects-to-skeleton component composition is responsible for that and is coupled to the adaption technique described in Sect. 3.4.2. The composition technique is merely the creation of an instance of the proxy and replacement of a correct instance of the skeleton component or a native component, with the created proxy instance.

74


3.4.4 Aspect Weaving Process In the aspect weaving process, the first step is the aspects-to-aspects composition. Finally, the aspects-to-skeleton component composition is done. Aspect composition process for the example presented Fig. 3.10 is shown in Fig 3.16.

Fig. 3.16. The Aspect Composition for the Motivating Example

In the first step, an aspect pipeline, which consists of log (log1) and crypto (crypto1) aspects, is created. In the second step, a proxy, which has a reference to the aspect pipeline, is created and the created proxy replaces the secureLogger skeleton component. At runtime, when a message comes to the proxy, it executes the aspect pipeline using the data access layer. Finally, it delegates the invocation to the secureLogger. To use the aspect weaver within a product, we provide a generic API for programmatically perform the aspect weaving. To make API generic, we decoupled the aspect building process from the decoration of the components of a particular product with the built aspects. For that purpose, we introduced an interface named as ObjectModelDecorator which is shown in Fig. 3.17.

Fig. 3.17. ObjectModelDecorator Interface

The implementation of ObjectModelDecorator is only the mandatory requirement to use the aspect weaver. However, if the default component model that is used to structure the aspects should be changed, then, an implementation of AspectObjectModel should be provided.

3.5 Aspect and Composition Definition Language

75

3.5 Aspect and Composition Definition Language ACDL provides a declarative way of defining aspects. An aspect definition is a meta-data describing the resources needed in implementing the functionality of an aspect. It also defines the point-cuts and advices, which are AOP constructs. 3.5.1 Design Goals •

•

•

ACDL must be a Domain Specific Language. ACDL should target for the domains of aspect orientation and enterprise integration. Therefore, by naming each language construct to reflect the terms of these domains, the power of the DSL can be drawn into the ACDL. All aspects should be defined in a consistent way. If the configurations of aspects differ from each other, it may be difficult to remember them. Moreover, the commonality in the configurations can be leveraged in implementing aspects, building a graphical DSL, etc. ACDL implementation must be extensible. The implementation should support adding new aspects and data types as needed and there should be a pluggable way to do that.

3.5.2 BNF Grammar for ACDL Figure 3.18 shows the BNF grammar of ACDL. 3.5.3 Using ACDL ACDL can be used for two purposes : defining aspects and defining aspect composition. Defining Aspects A definition of an aspect is a declaration of configuration parameters of the aspect. Although configuration parameters are different from aspect to aspect, the way of specifying those is consistent. Figure 3.19 shows an example of ACDL defining two aspects. In the ACDL in Fig. 3.19, there are two aspect definitions namely log and crypto. The log aspect is named as log1, and it has two log filters. One filter is based on regular expressions and other is for enabling logging. Furthermore, it should operate on the passive mode, in which logging is done asynchronously. The crypto aspect definition has four configuration parameters namely source, target, keystore, and cipher. The source specifies the data to be used for the cryptographic operation and the target specifies where the result of the

76


Fig. 3.18. The BNF Grammar for the ACDL

cryptographic operation should be kept. The cipher defines a cryptographic operation, a cryptographic algorithm, and a cryptographic service provider and so on. The BC in the provider stands for the bouncy castle open source cryptographic service provider. Defining Aspect Composition Figure 3.20 shows a simple ACDL example that demonstrates the aspect composition. It is based on Fig. 3.19 and only shows the definitions related to the aspect composition. Figure 3.20 demonstrates the aspect composition based on two AOP advices namely around and after. The only difference between Fig. 3.19 and Fig. 3.20 is the point-cut definitions: use after crypto1 and use before secureLogger.


77

Fig. 3.19. An ACDL Example Defining Aspects

Fig. 3.20. An ACDL Example Defining Aspect Composition

The first point-cut instructs to weave the log aspect after the crypto aspect, whereas the second one instructs to weave the log aspect before the secureLogger, which is the skeleton component. The ofmain keyword is to indicate that the secureLogger is an ESB component. Figure 3.16 graphically illustrates the result once the aspect weaving in Fig. 3.20 is completed. The combination of ACDLs shown in Fig. 3.19 and Fig. 3.20 can be used to implement the motivating example present in Fig. 3.10, with minor modifications - removing the filters from the log aspect configuration. Figure 3.21 demonstrates two types of aspect composition. One is using the before advice and other is using the aspect data type. Furthermore, it demonstrates a way to compose base system components with aspects. In the above example, there are three proxy aspects, which are used to compose base system components with aspects. The loadbalance aspect uses those proxy aspects as nodes to distribute the incoming traffic. The aspect data type enables to refer an aspect within another aspect. In other words, it

78


Fig. 3.21. An Aspect Composition Example in Detail

provides a way to achieve the within AOP advice. In the above example, ep1, ep2, and ep3 are the keys to look up the components of the base system. 3.5.4 Implementation of ACDL The implementation is a process of building the ACDLConfiguration object by parsing the ACDL configuration file. It is a two-step process: ACDL parsing and ACDL configuration building. Both of sub processes are described in the next sections. ACDL Parsing A set of implementations of the TokenParser are responsible for the ACDL parsing. Figure 3.22 shows the structure of the token parsers.

Fig. 3.22. The ACDL Token Parsing


79

Each parser reads corresponding tokens and performs a syntax validation of them. For example, the advice token parser reads an advice token and validates its syntax. ACDL Configuration Building ACDLConfigurationManager controls the ACDL configuration building process. It prepares the process by registering observers to listen to the lifecycle events of aspect definitions, such as adding and removing aspect definitions. Thereafter, it uses ACDLConfigurationBuilderDirector to build the ACDLConfiguration object. AspectDefinitionBuilder builds each part of the ACDL configuration. This whole process is an implementation of Builder [17] design pattern and Figure 3.23 shows this process.

Fig. 3.23. The ACDL Configuration Building

An aspect definition contains meta-data about an aspect and the aspectbuilding process uses it to create the corresponding aspect. The aspectbuilding process is an implementation of Builder pattern and is controlled by AspectManager, which in turn uses AspectBuilderDirector to direct the process. AspectManager also performs the lifecycle management activities of aspects such as initiating and destroying aspect instances. It is an implementation of ObjectManager [15] design pattern. AspectBuilderDirector is an observer of the ACDL configuration building process and listens to the events of the aspect definition building. These events contain ApectDefinition instances and AspectBuilder uses those to build aspects. The AO4ESB prototype implementation uses AspectDefinitionFinder for locating new aspect definitions and DataTypeFinder for locating new data types. We used a Java Service Provider API (SPI) based model to plug new aspects and data types.

80


3.6 Integration Layer The Integration layer decouples ESB environments from the AO4ESB framework to allow deploying the AO4ESB framework in a wide range of ESB environments. To use AO4ESB in a particular ESB, an implementation of the integration layer for that ESB is required. The integration layer consists of: •

•

Data Access Model The implementation for the data access model discussed in Sect. 3.2.1 is required. It includes interceptors, a message, and a message factory that provides methods to create messages and its parts including an error entry, a body, and headers. The message adapter, which converts the message into the argument expected by the component of the base system and vice versa, is required. Proxy and Skeleton Component Proxy is not a mandatory component as Java dynamic proxies can be used as a proxy to any java interface. The existing ESB components can be used instead of a skeleton component. However, the proxy and skeleton component implementations can be provided explicitly.

To integrate the AO4ESB into an ESB, the code for initiating, starting and stopping the AO4EBS should be written. For that purpose, we provided an API for the framework lifecycle management. The lifecycle management is an important aspect of a system. There should be a single point for controlling the lifecycles of the components of the system and the AO4ESB server manager provides that capability. It controls the lifecycles of aspects, channels and filter unites. Moreover, it provides the access to the aspect weaver, the aspect manager, and the aspect definitions manager. AO4ESB can be initialized by providing an AO4ESB server configuration instance and an AO4ESB server context instance. The server configuration consists of configuration information needed to initiate the framework such as the locations of the channel configuration, the AO4EB configuration, and the ACDL source file. The server context consists of the context information needed to initiate the framework such as instances of the interceptors.

3.7 Summary AO4ESB is a platform developed to support the realization of the multiple product lines of ESB. Our analysis of existing ESB products showed that they provide the same set of services and use different source codes to offer those services. Because this can be viewed as a kind of code scattering, we adopted the concepts of AOP. ESB services were identified as aspects. We presented an aspect development technique that can develop the software elements reusable across multiple product lines. An aspect adaptation technique

3.7 Summary

81

that can transparently transform the aspects into the components of different architectures was discussed. Moreover, an aspect library, which consists of eight aspects, was discussed. We developed each aspect using the aspect development methodology we formulated. To use the functionalities offered by aspects within a particular product, we developed an aspect weaver and presented in this chapter. The aspect weaver can structure the aspects based on architecture styles that are suitable for the products that are going to use the aspects. To define aspects and aspect composition, we developed a language, which features the external Domain Specific Language (DSL) approach. Next, we turn our attention to a design of the multiple ESB product lines based on our AO4ESB. The design is formulated based on the feature model.

4 A Design for Multiple ESB Product Lines

The interesting thing is when we design and architect a server, we don’t design it for Windows or Linux, we design it for both. We don’t really care, as long as we’re selling the one the customer wants. – Michael Dell Reusability of components, objects, code, stuff, ...whatever...remains the most unfulfilled promise offered by any software methodology that has reared its pretty head since Von Neumann. – Larry L. Johnson This chapter presents a design for multiple product lines of an ESB. It outlines an intuitive procedure for formulating multiple ESB product lines, using the AO4ESB as the product line platform. Furthermore, a comprehensive evaluation of the platform, being performed both quantitatively and qualitatively, is presented.

4.1 Realizing Multiple ESB Product Lines This section discusses a basic model for the multiple product lines of an ESB, including a feature model, an intuitive procedure for creating every ESB variation and individualized ESBs, and an approach for selecting the features of an ESB service for a particular ESB product, based on the feature model of the ESB service. 4.1.1 A Model of Multiple ESB Product Lines Figure 4.1 depicts the overall structure ofthe multiple ESB product lines using a feature model. Multiple ESB product lines consist of a set of single ESB product lines. A particular product line creates a family of similar ESB product using a

84


Fig. 4.1. A Feature Model for Multiple ESB Product Lines

single ESB architecture variation, and a set of ESB services and the features of them. An ESB product variation consists of a set of ESB services, an architecture implementation for the composition of ESB services, and a language for defining services and their compositions. The architecture can be a one of JBI, SCA, MQM, or Ad-Hoc. The ESB services for a particular ESB are selected from an N number of ESB services. The features of an ESB service can also be leveraged to extend a product line. For example, the features of the persistence aspect such as asynchronous data access, synchronous data access, XML database, object-oriented database, rational database, etc., make the opportunities for multiple product variations. 4.1.2 Creating Each ESB Variation As, with the AO4ESB, the already developed ESB services can be reused as-is in a new ESB, the producing of an ESB with a different architecture mostly require only the implementation of the ESB architecture. There are two approaches to develop ESB architectures: reuse and build. •

•

Reuse The ESB products that have been already developed both in-house and public (open source), can be used. However, the product line is a wellplanned reuse; therefore, a comprehensive evaluation of the design and implementation of the ESB should be performed prior to decide to reuse an ESB. For the evaluation of ESB products, both goal-oriented and quality attribute analyses should be used. Build Different ESB architectures should be developed and the development process should follow best practices, principles, and implementation approaches appropriately. Each ESB architecture must be evaluated based on standard architecture analyzing methods such as ATAM (Architecture Tradeoff Analysis Method) [8].

After building an ESB architecture, the next step is to develop a data access model presented in Sect. 3.2, and a proxy and skeleton component discussed in Sect. 3.4.2. If the target customer domain requires new ESB

4.1 Realizing Multiple ESB Product Lines

85

services, then those services also have to be developed. On completing that step, the further development of the ESB and the product line based on it is typically analogues to the development methodology exercised by a single product line. 4.1.3 Creating Individualized ESBs Typically, a software development process begins with identifying the problem followed by creating a solution that solves the problem in an optimal way. Only then, based on a comprehensive evaluation of the available technologies, the target technology is selected for implementing the solution. Aligning IT with the business is a key success factor for an enterprise and as a rule of thumb, it is necessary to build a software system that only creates a business value for the enterprise. Therefore, we believe that most customers prefer individualized ESBs. The first step in creating an individualized ESB is to select the most appropriate architecture that can support quality requirements of the solution architecture of the target customer. For example, for mission-critical and high volume applications, which require a higher reliability and availability, MQM (Message Queue Middleware) is the most suitable architecture for such applications. Secondly, the minimum required ESB services for implementing the solution should be selected. As another example is the trading domain. If the application integration problems of the trading domain involve many trading partners and a few third parties such as banks, government, then an ESB with a message model optimized for the communication protocols used in the trading is mostly suitable. It also needs ESB services such as EDI (Electronic Data Interchange) transforming, routing based on EDI, adapters that can adapt EDI messages to other formats such as XML. The selection of the features of an ESB service, also should consider the minimum required functionalities to realize the integration solution. The feature selection can leverage the feature models of the aspects, which the next section discusses. 4.1.4 Selecting the Features of an ESB Service An appropriate approach for selecting features of an asset is the feature model of the asset. In the product line space, feature modeling is already excessively using [24]. This section presents the feature models for three aspects in the aspect library. The feature models for other five aspects can be drawn based on the given feature models, the design of those aspects presented in Sect. 3.3, and the literature survey of the aspects presented in Sect. 2.2. In the aspect development methodology presented in Sect. 3.2, a feature of an aspect is used to codify the commonalty and variability of the aspect. As the Intuitive Requirement outlined in Sect. 3.2 serves as a means of identifying the mandatory features of an aspect, the feature model is drawn based on it.

86


The initial feature model then evolved based on the requirements gathered from the domain analysis of the aspect such as the literature survey of the aspects presented in Sect. 2.2. The Feature Model of the Log Aspect As per the Intuitive Requirement of the log aspect presented in Sect. 3.2.2, the mandatory features of the log aspect are the log sources that generate logs, a medium to transport the generated logs, and the destinations, which process the logs. Based on the domain analysis presented in Sect. 2.2.1, the variation points for the log aspect can be identified. Figure 4.2 shows the feature model for the log aspect.

Fig. 4.2. The Feature Model of the Log Aspect

Every log aspect variation needs a log source, a log message channel, and a log sink. In the log aspect implementation, there is a single log source implementation. The default log formatter is the text formatter and the default log sink is the console. The local method invocation based channel is the default log-message- channel. To customize the log aspect, it is possible to use log filters, log message channels, log formatters, and log sinks. The Feature Model of the Cache Aspect As per the Intuitive Requirement of the cache aspect presented in Sect. 3.3.5, we selected cache loading and cache storages as the mandatory features for the cache aspect. To achieve a higher reliability and availability, a cache should have backup stores to keep the cached data. The performance of the cache is strongly related to the strategies that populate the cache with the data. The cache coherence is related with the mechanisms of both cache loading and cache controlling. Based on the domain analysis presented in Sect. 2.2.3, the variation points for the cache aspect can be identified. The feature model for the cache aspect is shown in Fig. 4.3. As per Fig. 4.3, every cache aspect variation needs the implementations of a cache and a cache loader. The default cache used the in-memory cache store. A reactive loader, which retrieves the data using a synchronous programming model, is the default cache loader. To customize the cache aspect, it is possible to use cache loaders, cache implementations, cache storages, and cache controlling mechanisms.

4.2 The Evaluation of the Product Line Platform

87

Fig. 4.3. The Feature Model of the Cache Aspect

The Feature Model of the Load Balance Aspect As per the Intuitive Requirement of the load balance aspect presented in Sect. 3.3.7, the main feature is an abstraction for identifying a destination to forward the requests received by the load balancer to the ultimate destinations where the requests are processed. Based on the requirement for the session affinity, it is possible to identify two board categories for identifying a destination: session-less and sessionaware. Both of those categories follow the same procedure - identifying a set of destinations with good health and selecting a single destination from the healthy destinations. Therefore, we have selected the mandatory feature of the load balance aspect as either session-less or sessionaware load balancing. Based on the domain analysis presented in Sect. 2.2.10, the variation points for the load balance aspect can be identified. The feature model for the load balance aspect is shown in Fig. 4.4.

Fig. 4.4. The Feature Model of the Load Balance Aspect

Every load-balance aspect variation should support either a session-less or session-aware load balancing. The default load-balance algorithm is round robin. To customize the load balance aspect, it is possible to use load-balance algorithms, the types of the session, and session storages.

4.2 The Evaluation of the Product Line Platform This chapter analyzes the product line platform presented in this research. We broadly divide our analysis into two major categories: quantitative and qualitative. Each category further subdivides appropriately to make the analysis fluent.

88


4.2.1 Quantitative Analysis We present two sets of our platform evaluations under the quantitative category. The first evaluation measures the overhead of the aspect adaptation. The second one comprehensively evaluates our platform including the aspects and the methodologies used in the design, adaptation, and composition of the aspects. Overhead of Aspect Adaptation As per the discussion in Sect. 3.4.2, the cost associated with the adaption technique is mainly attributed to the implementation of the message. However, the effect on the performance can be limited to a single additional method call by implementing the message as a wrapper for the context object being passed between the components of the product that uses the aspects. We measured the overhead by adapting the log aspect to a component of Synapse ESB. We collected two data sets direct innovation of the log aspect and indirect invocation through a synapse proxy. We attempted to assess the increase in the overhead, when the numbers of aspects are increased. Table 3 shows the collected data. The test suite was a Java test case, which was triggered programmatically. It was executed 100 times sequentially for each data set, and then we took the average value. The overhead is calculated as (indirect invocation direct invocation). We observed that the overhead mostly would not make a huge negative effect on the overall performance of the system. Table 4.1 shows the collected data and Fig. 4.5 graphically illustrates those data. Table 4.1. The Overhead of the Aspect Adaptation Number of 1 Log Aspect Instances Overhead 0.001 (Millisecond )

2

3

4

5

0.167

0.334

0.343

0.400

As per Fig. 4.5, the overhead of the aspect adaptation is lineally proportional to the number of adapted aspects. However, the overhead is very low. The Case Study with Apache Synapse We did a case study, which uses our platform in a real world ESB. We used Apache Synapse open source ESB. To use our platform, Synapse only needed implementations of data access layer, interceptors, and proxy and skeleton component. There was no refractoring in the Synapse. The case study involved twenty-two scenarios and this section describes those.


89

Fig. 4.5. The Overhead of the Aspect Adaptation

Apache Synapse. Apache Synapse [6] is an open source ESB. Its main components are proxy services, mediators, endpoints, and tasks. The proxy services can act as the proxies to external business services(service providers) and the synapse tasks can execute the application tasks that should take place immediately just after the synapse starts up. The mediators provide ESB services such as transformation and routing, whereas the endpoints encapsulate the information about external services (service providers). In the current implementation, the AO4ESB only contains a few aspects. Therefore, this case study uses a few synapse components to get the additional functionalities required to implement some scenarios, and those synapse components are described in the following. The sequence mediator organizes and invokes a set of mediators sequentially. Sequence is also a mediator. There are two special sequences namely main sequence and fault sequence. The main sequence consumes any messages that have not been consumed by either the proxy services or any other services deployed in the Synapse, and the fault sequence acts as the default fault handler. The send mediator can communicate with external services. The in mediator filters responses and the out mediator filters requests. In additions, this case study uses the callout mediator to perform blocking web service invocations, the property mediator to manage properties of the context object being passed among mediators, the drop mediator to halt a message flow, and the header mediator to manage the headers of a message. Scenarios. These scenarios demonstrate how the AO4ESB approach can provide ESB services. Appendix A has included the resources used by a selected set of scenarios and the documentation of the AO4SB includes detailed de-

90


scriptions about each scenario including sample configurations, and how to set up and run samples. There are twenty-two scenarios and next sections discuss each scenario focusing only on the high-level details. 1. Compose the Log Aspect with Multiple ESB Components This scenario performs the logging prior to execute all synapse components of a particular component type. Although, in this scenario, the component type is the send mediator, it can be any type. The point-cut defined in the log aspect configuration uses the select operation as for-each to select all components of a particular type. The ACDL for this scenario is in Appendix A.1.2. 2. Log Filtering This scenario demonstrates how to control the logging using the log filtering. Log filtering reduces the effects of the logging on the run-time performance of the system. There are seven filters in the implementation of the AO4ESB and this sample uses three of them namely XPath based, regular expression based and log-enable 3. Passive Logging This scenario demonstrates an asynchronous model for the logging. The asynchronous model is a result of the design decision of separating a log source and log sinks through a log message channel whose implementation can be in any form. This scenario uses a queue-based channel implementation, to allow the asynchronous model for the logging, and to enable a simple staged processing. The asynchronous model reduces the effects of the logging on the run-time performance because a separate thread in the background does the formatting and persistence of log records. 4. Secure Logging This scenario composes the security aspect and the log aspect to encrypt log messages prior to the logging. The log aspect that generates log records is weaved before the security aspect and the log aspect that displays the final encrypted log message on the console is weaved after the security aspect. The ACDL for this scenario is in Appendix A.1.3. 5. Saving Log Records in a Database This scenario composes the persistence aspect and the log aspect to save log records in a database. The persistence aspect is weaved after the log aspect. 6. Sending Log Records to Remote Log Analyzers This scenario demonstrates the capability of separating log analyzing from the collecting of log records. In this scenario, because the log analyzer exposes a web service, the log records are formatted into SOAP messages using the SOAP log formatter. Furthermore, this scenario uses the proxy aspect, which composes ESB components to aspects. Here, the callout mediator is composed into the proxy aspect so that it can be used to send the formatted log records to the remote log analyzer.


91

7. Replacing Errors This demonstrates the replacement of the original error message with a custom message, and it is a common scenario of an enterprise, as the technical details of errors need to be hidden from the end-users. Furthermore, the leakage of sensitivity information needs to be prevented and end-users should only receive the error messages indicating business problems. The ACDL for this scenario is in Appendix A.1.4. 8. Replacing and Logging Errors This scenario is similar to the scenario seven except this additionally logs the original error message. This also demonstrates the approach that implements the within aspect advice using aspect references. An aspect reference enables an aspect to access other aspects in a loosely coupled manner. Furthermore, this scenario uses two error handlers namely log and replace in a single exception handler aspect. 9. Retrying for Communication Errors In this scenario, the retryable exception handler retries for temporal failures on the communication with external services (service providers). The ACDL for this scenario is in Appendix A.1.5. 10. Retrying for Data Access Errors This scenario demonstrates the retrying for data access errors and is implemented by composing the exception handler aspect after the persistence aspect. 11. Secure Persistence This scenario demonstrates persistence of data along with its hash value so that data integrity check can be performed at later. First, the data from the response message is extracted and its hash value is computed. Finally, it saves the data and its hash value in the database. The crypto aspect is weaved before the persistence aspect in order to calculate the hash value. The ACDL for this scenario is in Appendix A.1.6. 12. Selective Persistence In this scenario, only if the new data differs from the exiting data, the new data is saved. This uses the comparison of hash values to detect whether data is new or not. 13. Caching Responses This scenario demonstrates the caching of the responses from service providers to the requests from service consumers. It is implemented using two instances of the same cache aspect. One instance is weaved before calling the external service and other after calling the external service. The ACDL for this scenario is in Appendix A.2.2. 14. Caching Database Records This demonstrates the caching of database records and is implemented by weaving the cache aspect around the persistence aspect. The ACDL for this scenario is in Appendix A.3.2. 15. Reactive Cache Loading This demonstrates the populating of the cache with the data on demand

92

16.

17.

18.

19.

20.

21.

22.


when an application requests for the data. This scenario caches message responses and if there is no response for a request in the cache, then the cache aspect does a blocking call to the external service and gets the response, keeps it in the cache, and then sends back it to the client. Proactive Cache Loading This demonstrates the populating of the cache proactively. This scenario caches database records and the asynchronous pull cache loader loads those database records into the cache. The cache aspect only serves requests from the cache. Round-Robin Load Balancing In this scenario, the load is distributed in a round robin passion across a set of destination pipelines. This is an example for the non-adaptive and static load balancing. The ACDL for this scenario is in Appendix A.4.2. Dynamic Round-Robin Balancing based on the Response time This demonstrates the dynamic load balancing capability. In dynamic load balancing, the load balance decision is adjusted based on the heath check metrics such as the response time, the queue length. This sample uses the parameter of the metrics as the response time, which is measured by the monitoring aspect. The ACDL for this scenario is in Appendix A.4.3. Dynamic Round-Robin Balancing based on the Remaining Capacity of Queue This scenario is similar to the scenario eighteen except this uses the remaining capacity of the queue of the first queue-based message channel in the destination pipeline. More information of the queue-based message channel is in Sect. 3.4.3. Session-Affinity Load Balancing based on the Client IP This scenario demonstrates the session affinity load balancing. There are seven ways for the session affinity load balancing and more information is in Sect. 3.3.7. This scenario uses the IP address of the client as the session identifier and all requests from a same client are processed through a same pipeline until the session expires. The ACDL for this scenario is in Appendix A.4.4. Session-Affinity Load Balancing based on the Basic Authentication Header This is similar to the scenario twenty except this uses the HTTP basic authentication header as the session identifier. Session-Affinity Load Balancing based on the Cookie The cookie-based session is a server-initiated session as a server generates cookies. The load balancer forwards the requests with a same cookie to the server, which the cookie was generated. The ACDL for this scenario is in Appendix A.4.5.

Discussion. All scenarios are real world scenarios that typically an ESB should support. Some scenarios only needed a single aspect, whereas others needed a composite of aspects and those composites were created only using the aspect weaving mechanism. A few Synapse components were used in some scenarios,


93

mainly due to the unavailability of aspects that implement the functionality of those Synapse components. Therefore, it is evident that by developing ESB services as aspects, the AO4ESB approach can provide all ESB functionality Synapse needs. As a result, it is possible to remove most ESB services from Synapse and make Synapse to use the platform. In other words, Synapse can be derived from the platform. •

•

•

•

Reusability of Aspects Aspects only depend on the data access layer, and we have not done any Synapse specific modifications to the aspects. As per the case study, we have used the same aspect in multiple scenarios with different types of other aspects. For example, the log aspect has used in seven scenarios with four different aspects. Modifiability of Aspects As per the case study, most of the aspects have provided diverse features. For example, the cache aspect has provided message caching, database record caching, synchronous cache loading, and asynchronous cache loading; the load balance aspect has provided session less and session affinity load balancing, basic round robin and dynamic round robin, etc. Most of these features have implemented as extensibility points for the initial design developed based on the Intuitive Requirement. All of these features are orthogonal and the modifications are local to a particular feature implementation. Aspect Adaptation We have not done any Synapse specific modifications to the aspects, and we used the Synapse architecture as is. From this observation, it is evident that the aspects in our aspect library can be transparently adapted to different architectures. In other words, the aspects in the aspect library can be reused as is in products with different architectures. Aspect Composition Each scenario involves the aspect composition. Each of AOP advises have used in more than one scenario. Using a set of basic services such as log, persistence and crypto, the aspect composition successfully created complex services such as secure logging, reliable logging, etc. As the aspect composition is not coupled to a particular architecture, we believe that aspect weaver can be successfully used in different architectures without any modifications to the basic design or the methodology that is used the aspect composition.

4.2.2 Qualitative Analysis Next sections present a detailed qualitative analysis of the results of the AO4ESB research project. First, the goals of the project are evaluated and finally, the quality attributes of the design and implementation of the AO4ESB are discussed.

94


Goal Oriented Analysis This analysis focuses on two main goals of this research project: separating crosscutting concerns of heterogeneous ESB products and providing a platform for multiple product lines of ESB. Goal 1 - Separating Crosscutting Concerns of Heterogeneous ESB Products This research project provides approaches for identifying and modularizing crosscutting concerns of ESB products. These concerns mainly are ESB services such as routing, security, caching, transformation, and so on. Identifying Crosscutting Concerns. Literature survey identified and analyzed a set of ESB services that have been scattered across different ESB products. In additions, it provided a set of aspect mining techniques and features mining techniques to identify aspects and other orthogonal functionalities. Detailed descriptions of ten aspects were provided in the literature survey and those are logging, security, caching, exception handling, validation, persistence, transaction, fault tolerance, monitoring, and load balance. Modularizing Crosscutting Concerns. The implementation of the AO4ESB used AOP (Aspect Oriented Programming) to modularize identified aspects and other orthogonal functionalities related to the ESB. The AO4ESB framework consists of a language to define aspects, an API to implement aspects and an aspect weaver to compose aspects to both the components of a target ESB and other aspects. Furthermore, it provides an aspect library, which consists of eight aspects. Our aspect development methodology is to design and implement aspects as the assets, which are reusable across multiple architectures. Therefore, by identifying and modularizing crosscutting concerns of ESB products, the AO4ESB successfully has achieved the goal of separating crosscutting concerns of heterogeneous ESB products. Goal 2 - Providing a Platform for Multiple Product Lines of ESB A product line platform typically provides a core asset base that can be used to produce a product family. It exploits the variations that make products different. For an ESB product line, ESB architectures, the features of an ESB, and the heterogeneity in the customer base are the main variation points. The case study presented in the Sect. 4.2.1 concludes that with the AO4ESB it is possible to implement scenarios related to the ESB successfully. In that study, the integration of the AO4ESB to the real world ESB was completely transparent as there was no refractoring. Therefore, the integration of the AO4ESB with other ESB variations mostly will only require a minimum effort. The component assembler, the component library, and the component definition language are three vital ingredients of a product line platform. The


95

AO4ESB provides an aspect weaver, an aspect library, and an aspect definition language. The model for the ESB product lines presented in Sect. 4.1 discussed how the AO4ESB could be used to realize multiple product lines of an ESB. Quality Attribute Analysis This analysis explores the software quality attributes of the design and implementation of the AO4ESB. The quality attributes are selected from some standard quality attributes suggested in [66]. Furthermore, the Architecture Tradeoff Analysis Method (ATAM) [8] also influenced this analysis. Functionality Definition. The ability of the system to do the work for which it was intended. The case study with the apache synapse ESB was intended to estimate the capabilities of the AO4ESB to provide ESB services. It consists of twenty-two ESB scenarios. Therefore, the case study showed that the AO4ESB would successfully support ESB scenarios. In additions, the case study evaluated the ease of integration of the AO4ESB with a real world ESB. The integration to the apache synapse was merely an implementation of the integration layer of the AO4ESB, and there was no refractoring. Although that fact does not claim that the AO4ESB can be deployed on any ESB, it should be possible to deploy the AO4ESB in a wide range of ESB as per the discussions in the data access layer, the aspect development , the aspect adaptation, and the aspect composition. The model for the ESB product lines presented in Chap. 4 discussed the capabilities of the AO4ESB to realize multiple product lines of an ESB. The AO4ESB provides three of main ingredients of a typical product line platform: the component assembler, the component library, and the component definition language. As the aspects in the aspect library can be used as-is in different ESB architectures, our approach provides the systematic reuse across different products. Therefore, the AO4ESB can be a platform for multiple product lines of ESB. Therefore, it is evident from the above discussions that the AO4ESB can support the functionality, which it should provide. Performance Definition. The response time, utilization, and throughput behavior of the system. This research project did not measure the system performance except the overhead of the aspect adaptation presented in Sect. 3.4.1. However, there are design decisions that enable to achieve a higher runtime performance.

96

•

•

•


The aspect weaver leverages architecture styles suitable for target products With a suitable architecture style, our aspect weaving can be used to gain a higher performance. We believe the default architecture style, which the Pipe and Filters architecture pattern, can support to achieve a better performance. The Pipe and Filters pattern enables both parallel and pipeline processing, which are widely used methods for achieving a higher overall system throughput. The implementation of the pipe component of the pattern uses the concept of a channel, which can support the SEDA [67] model that was designed to achieve high-performance. In the SEDA model, the application processing is decomposed into stages separated by queues and each stage, which is internally event-driven and typically non-blocking, performs a subset of the processing. The AO4ESB provides a queue-based channel that supports a subset of the features of the SEDA model. The design of the log aspect Typically, logging introduces an overhead and the log aspect is designed to minimize it. In the log aspect, a log source routes the raw log records to log sinks through a log message channel. The log message channel decouples the log source from the log sinks and can be implemented by using a wide variety of technologies such as in-memory queues and MOM (Message Oriented Middleware). The SEDA [67] model can also be used for implementing it. The AO4ESB provides a queue-based channel that allows the passive logging, which enables to minimize the logging overhead. Furthermore, the log aspect generates log records in a way that minimizes the overhead. The log generation is a stepwise process and the log filtering is applied at each step. The use of an asynchronous model An asynchronous model, which enables to achieve a better performance, is used in many aspects. The proactive cache loading of the cache aspect, the health check monitoring of the load balance aspect, the aggregation of statistics in the monitoring aspect, and the session expiration of the session-affinity load balancing are four examples for the use of an asynchronous model.

Security Definition. A measure of systems ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users. Although providing a solution to achieve complete security requirements of a system is beyond the scope of this project, the AO4ESB consists of a crypto aspect that can support the security requirements of other aspects. For example, crypto aspect can be used to secure a log message and to check the integrity of cached items or database records. The case study presented in the Sect. 4.2.1, consists of scenarios demonstrating the secure logging and the secure persisting.


97

Availability and Reliability Definition. The measure of time that the system is up and running correctly; the length of time between failures and the length of time needed to resume operation after a failure. Although statistical measures of availability are not available in the results of this research, the AO4ESB was designed to support availability requirements of an integration middleware. The channel concept used in the Pipe and Filters architecture pattern allows implementing a channel using different technologies. A channel implementation based on the message-oriented persistence communication methods such as the message queues can provide high availability, reliability, and scalability. Furthermore, the exception handling aspect can be used to achieve a desired level of fault tolerance. It consists of a retryable exception handler that can retry for both communication and data access failures and there are scenarios in the case study demonstrating these capabilities. The retrying for transient failures enhances the fault tolerance of the system. Usability Definition. The ease of use and of training the end users of the system. Sub qualities. learnability, efficiency, affect, helpfulness, control. AO4ESB provides a set of documents including a sample guide, an architecture guide, a development guide, and an ACDL guide, and they are useful for developers to both learn and develop the AO4ESB. ACDL is based on the concepts of the DSL and consists of the language constructs that reflect the concepts, facts, and terms in the both AOP and the ESB. Therefore, it makes easy to learn and remind the ACDL for users that possess a basic knowledge of the AOP and ESB. Furthermore, the ACDL is in the textual form and can be implemented with a graphical DSL, which enhances the usability of the ACDL. AO4ESB research project does not provide tools such as management tools and development tools. Most of the existing tools used for the development of Java based products can also be used to develop the AO4ESB. Interoperability Definition. The ability of two or more systems to cooperate at runtime. AO4ESB project has not been tested with other AOP systems to assess the interoperability. However, it is possible to identity the effects on the interoperability. •

Interoperability with other Java-based AOP Systems The aspect weaving mechanism used in the AO4ESB is based on neither the byte code modification nor the code generation. The source code of the AO4ESB is static and ordinary Java codes. Therefore, the interoperability with other Java-based AOP systems would not be affected.

98

•


Interoperability with heterogeneous systems Providing the interoperability required for collaborating with heterogeneous systems is beyond the scope of this project. The implementations of open standards such as Web Service standards are required to achieve such interoperability and those standards have not been implemented in the AO4ESB.

Modifiability Definition. The ease with which a software system can accommodate changes to its software. Numerous design decisions and implementation approaches enhance the modifiability of the AO4ESB. •

•

•

•

Configurability Each major ingredient of the AO4ESB is configurable. ACDL enables configuring the aspects and their composition. The aspect weaving process can be controlled with the channel configuration and the AO4ESB system configuration. Component-based development AO4ESB follows a component-based approach. Aspects are the reusable components and the aspect weaver is the component assembler. The ESB services are provided only by assembling aspects in a prescribed way. The aspect development methodology is to develop aspects as reusable assets. Loose coupling All aspects are loosely coupled at both the compile time and run-time except the load balance and monitoring aspects as they are coupled at the compile time. The monitoring aspect was introduced to implement some scenarios related to the load balancing and the decoupling of those aspects is only a trivial task. The integration layer of the AO4ESB decouples the AO4ESB from the ESBs that use the AO4ESB. It makes aspects autonomous. Due to this level of loose coupling, an aspect implementation can be changed without affecting other aspects. Program to an interface, not an implementation The aspects and other components of the AO4ESB follow the design principle program to an interface, not an implementation appropriately. This allows the AO4ESB to support an adequate level of modifiability by leveraging two principles namely information hiding and separation of concerns.

Portability Definition. The ability of a system to run under different computing environments. The portability of the AO4ESB can be evaluated by considering two main categories of deployment environments: different ESB products, and different hardware and operating systems.


•

•

99

Deploying and running on different ESB products The integration layer decouples ESB environments from the AO4ESB framework to allow deploying the AO4ESB framework in a wide range of ESB environments. Furthermore, as discussed in the aspect adaptation and composition sections, the AO4ESB can be used in the ESB products with different architectures. Deploying and running on different hardware and operating systems. AO4ESB uses Java as the general-purpose language for its implementation and Java provides the portability required for deploying and running a software system on different hardware and operating systems. Therefore, the AO4ESB inherently possesses the capability to deploy and run on heterogeneous hardware and operating systems.

Reusability Definition. The degree to which existing applications can be reused in new applications. Reusability is one of the fundamental quality attributes, which enables to realize a product line. There are two main categories of reusability. •

•

Reusability of the AO4ESB in other applications Aspects are designed and implemented with planned reuse to enable the realization of ESB product lines. All designs and implementations are based on best practices, patterns, and implementation approaches, found in the research literature. AO4ESB includes an aspect library, which encapsulates all reusable ESB services. The integration layer allows the reuse of the AO4ESB in a wide range of ESB environments. Furthermore, the architecture pattern used for the aspect composition is pluggable, which make the aspect composition suitable for a wide range of middleware. Reusability of existing applications in the AO4ESB Each aspect provides a way to integrate existing software libraries in the corresponding domain of the aspect. For example, the log aspect integrates Log4j [62], the cache aspect integrates Ehcache [64], and Quartz [65] provides the job scheduling that is used by many aspects. Furthermore, the channel concept enables to integrate existing technologies such as Message Oriented Middleware (MOM). The case study presented in Sect. 4.2.1 demonstrated the reuse of ESB components of an existing ESB product within in the aspects. Furthermore, the design of the multiple ESB product lines presented in Sect. 4.1 discussed the opportunities to reuse existing ESB products and their architectures.

Cost and Schedule Definition. The cost of the system with respect to time to market, expected project lifetime, and utilization of legacy and COTS systems.

100


The product line approach is invented to produce a family of products without undue cost, risk, and efforts, comparing to the single product development. It reduces the time to market for a product and enables to provide the solutions that each customer domain wants. AO4ESB provides a base platform of multiple product lines of ESB. It allows the large-grained reuse (every ESB service) across different ESB product families. Therefore, the cost and schedule quality attribute is supported by the AO4ESB. Furthermore, the utilization of legacy and COTS systems can be done efficiently with an AOP based approach and the literature survey discussed it. On the other hand, as discussed under the quality attribute reusability, the AO4ESB already has utilized existing software libraries and products. Marketability Definition. The use of the system with respect to market competition. Section 4.1 discussed the business opportunities that multiple product lines of an ESB can create. Both ESB products and customer bases are heterogeneous, and ESB multiple product lines enable to a single ESB vendor to dominate the ESB market by producing each ESB variation and providing individualized ESBs. Conceptual Integrity Definition. The integrity of the overall structure that is composed from a number of small architectural structures. In the AO4ESB approach, it is recommended to capture all ESB services such as routing, transformation, and security into aspects and to use the aspect weaving to compose those aspects and other ESB specific components to make the final ESB system. This enforces the conceptual integrity by creating an ESB runtime structure consists of the aspects that are composed by only means of the aspect weaving. To enforce the conceptual integrity, the architecture should do similar things in similar ways [8] and the AO4ESB follows this principle. For example, the channel concept used in the aspect weaver and the log message channel used in the log aspect are implemented by using the same kind of approaches and technologies. Another example is the use of the Event Channel pattern to distribute both the monitoring aspects events and control buss events. Correctness Definition. Accountability for satisfying all requirements of the system. The AO4ESB should provide ESB services or more broadly integration infrastructure services, and should enable to realize multiple product lines of ESB. The case study presented in Sect. 4.2.1 showed the capabilities of the AO4ESB to provide ESB services. The design for the ESB product lines, presented in Sect. 4.1 provided a hypothetical procedure for formulating multiple product lines of an ESB by using the AO4ESB. Therefore, the AO4ESB can support successfully most of the main requirements of it.

4.3 Summary

101

4.3 Summary We discussed a design for multiple ESB product lines, to be realized using the AO4ESB as the product line platform. The design is intuitive and describes how to create new ESB product variations, individualized ESBs, and selecting features of an ESB service for a particular ESB product. We evaluated the AO4ESB using both quantitative and qualitative approaches. The quantitative analysis includes a case study and a measurement of the overhead associated with the aspect adaptation. A case study with a real world ESB was used as a quantitative method to assess the AO4ESB for supporting real world scenarios that typically an ESB should support. Quality attributes and goal-oriented analyses were performed as the qualitative approach. The goal-oriented analysis emphasized that most goals of the research have been achieved successfully. The quality attribute analysis assessed the sustainability, adaptability, and extendibility of the design and implementation of the AO4ESB. Next chapter concludes our research work.

5 Conclusions

A conclusion is the place where you get tired of thinking. – Arthur Bloch I think and think for months and years. Ninety-nine times, the conclusion is false. The hundredth time I am right. – Albert Einstein This chapter presents the conclusions of our research work as well as the opportunities for further research. First, it summarizes the key contributions of the research followed by a discussion about the limitations of the implementation of the research project. Finally, it proposes several directions for further research.

5.1 Contributions Today, enterprises are utilizing IT to automate their business processes. Typically, a business process spans over heterogeneous applications and to execute such a business process successfully, IT should provide robust and scalable solutions for integrating those applications. An ESB (Enterprise Service Bus) is a middleware supporting EAI (Enterprise Application Integration). ESB products are heterogeneous in terms of architectures, and features. By producing each ESB variation, a single ESB vendor can capture a large part of the ESB market. An ESB has reached industries from wide ranging application domains including trading, healthcare and banking. Most probably, each customer domain prefers an individualized ESB, which is customized to solve the integration problems of the target customer domain efficiently. With individualized ESBs, a single ESB vendor hence can dominate the ESB market. The development of every ESB variation and individualized ESBs, requires a systematic approach to create a large set of ESB products efficiently. The

104

5 Conclusions

Software Product Line Engineering (SPLE) can provide such a systematic approach. It is an engineering discipline to realize and maintain a software product line (SPL), which is a family of products, derived from a common platform. Therefore, a suitable solution for producing a large set of ESB products is an ESB product line. However, traditional SPL approaches usually develop products with the same architecture. As there are different ESB architectures, the solution should be the multiple product lines of ESB products. This research attempted to develop a platform that can be potentially used to support the development of multiple product lines of ESB products. A platform of a traditional single product line provides a systematic reuse only within a single product family. A platform for multiple product lines should provide a systematic reuse within multiple product families and be capable of producing products with different architectures reusing the same set of core assets. In this research, we have analyzed existing ESB products as black boxes to identify them as products that have been built using a set of services from a universal ESB service library. Thus, if we were able to form a universal ESB service library, then that would allow us to formulate an ESB product line successfully. For this purpose, we developed a platform whose primary core assets are ESB services that are adaptable for most ESB variations. ESB architecture was selected as the variability and ESB services were selected as the commonality in order to gain a higher reuse. Different ESBs use different source codes to offer the same service. Because this can be viewed as a kind of code scattering, we adopted the concepts of AOP. We named our platform as AO4ESB (Aspect Orientation for ESB) as it is an AOP-based framework for an ESB. The main ingredients of the AO4ESB are: 1. Aspect Library Aspect library consists of eight aspects namely log, crypto, cache, load balance, exception handling, monitoring, persistence, and proxy. 2. Aspect Weaver To use the functionalities offered by the aspects within a particular product, the aspects should be composed into that product. For that purpose, we developed an aspect weaver. It can structure the aspects based on architecture styles that are suitable for the products that are going to use the aspects. 3. Aspect Composition and Definition Language(ACDL) ACDL uses a DSL-based approach in order to bring the advantages of DSL for expressing domain specific problems and their solutions. ACDL provides constructs to define both the aspects and their compositions. Apart from the main contribution, it is possible to identify another three important contributions.

5.3 Further Research

105

1. Aspect Development Technique The aspect development technique is to develop software elements, which are reusable across multiple product families. 2. Aspect Adaptation Technique The aspect adaptation technique can transparently transform the aspects into the components of different architectures. 3. A Design for Multiple ESB Product Lines This provides an intuitive procedure and basic design for developing multiple product lines of ESB products using the AO4ESB as the product line platform. Apart from the above contributions, this research provided a comprehensive analysis of the research literature, which provided a foundation for this research. Chapter 2 is dedicated for this purpose. First, it discusses the concepts of the ESB, emphasizing its role in providing application integration solutions, the heterogeneity in the ESB products and customer base. Thereafter, it discusses the concepts of the AOP including fundamentals, the aspect weaving strategies and approaches. Finally, it describes the concepts of DSL and its power for expressing domain specific problems and their solutions. The second part of Chap. 2 discusses ten aspects related to an ESB in detailed including the role of them in an ESB, basic concepts of them, and best practices and existing approaches for designing and implementing them. The later part of Chap. 2 describes AOP framework architectures, the aspect mining and aspectual refractoring, and previous AOP-based product line attempts. Finally, it discusses the previous research attempts related to this research

5.2 Limitations The case study presented in this research only uses a single real world ESB. Therefore, the limitations of the prototype implementation cannot be exactly identified. The integration with the real world ESB was completely transparent as there was no refractoring. Considering the above fact and our methodologies for the development, adaptation, and composition of aspects, we believe that our approach can be an infrastructure for the realization of multiple product lines of ESBs. However, as the evaluation of the platform was only with a single ESB variation, this study cannot claim that the integration with other ESB variations will not need any modification to the API of the prototype implementation.

5.3 Further Research A potential research opportunity is the proof of the concepts for multiple ESB product lines. This is the realization of the design for multiple product

106

5 Conclusions

lines presented in this research. To extend the AO4ESB approach to a wide range of middleware is another future research opportunity. AO4ESB follows a component-based approach. Aspects can be reused as-is in different architectures. The aspect weaver structures the aspects based on a given architecture style. Therefore, it should be possible to extend this work to a wide range of middleware. AO4ESB is a prototype and it is necessary to improve it prior to use it in a production environment. Therefore, enhancing the platform for a production environment is also a major future work.

A Case Study Resources

This appendix describes the resources used in the case study presented in Sect. 4.2.1.

A.1 Scenarios 1 - 12 This section presents the resources used in the scenarios from 1 to 12 in the case study. A.1.1 The Synapse Configuration Figure A.1 shows the synapse configuration shared by the scenarios from 1 to 12. In Fig. A.1, the main is the default sequence that the messages, which Synapse receives, are processed. It consists with in mediator to process request messages and out mediator to process responses. The inSequence performs the request message processing, and is called by the in mediator in the main sequence. It only has a send mediator that sends messages to the external service. The outSequence performs the response message processing, and is called by theout mediator in the main sequence. The logSendSequence sends log messages to a remote log analyzer service, and is used by the scenario 6. The send mediator is the only ESB service that has been taken from the Synapse, and it was because the AO4ESB has not an aspect providing message sending. All other integration services are provided by the AO4ESB. A.1.2 The ACDL for Scenario 1 Figure A.2 shows the ACDL for Scenario 1. The ACDL in Fig.A.2 defines how to apply the logging aspect to the synapse using the AO4ESB. As per the synapse configuration in Fig. A.1,

108


Fig. A.1. The Synapse Configuration for Scenarios 1-12

Fig. A.2. The ACDL for Scenario 1

there are three send components. The logging aspect is weaved prior to each send component. Figure A.3 graphically illustrates the aspect weaving for the ACDL in Fig. A.2. As per Fig. A.3, prior to the aspect weaving, the log aspect is in the aspect library and the send component is in the Synapse. By weaving the log aspect to the send component, the required integration service is produced. In the figure, the numbers show the message flow sequence. After the sender receives

A.1 Scenarios 1 - 12

109

Fig. A.3. The Aspect Weaving for Scenario 1

a message, it gives the message to the log aspect in order to perform logging. After the logging is completed, the sender performs the message sending. A.1.3 The ACDL for Scenario 4 The configuration in Fig. A.4 demonstrates the implementation of the secure logging complex ESB service as a composition of the log aspect and crypto aspect. The log aspect logexample1 generates a log message and then handover it to the crypto aspect in order to encrypt it. Finally, the log aspect logexample2 logs the encrypted message. Figure A.5 graphically illustrates the scenario presented in Fig A.4. As per Fig. A.5, Log and security (crypto) aspect are organized as a pipeline, which is created by the aspect weaver. When the send component receives a message, it first executes the pre-processor pipeline, which in turn executes the aspects in the pipeline in sequence. After the processing in the pipeline completes, the next ESB component is executed. A.1.4 The ACDL for Scenario 7 The ACDL in Fig. A.6 defines an exception handler aspect, which has an exception handling policy that instructs to replace the existing error mes-

110



sage with the given message. The exception handler aspect weaves before the outSequence to enable to handle errors in responses. A.1.5 The ACDL for Scenario 9 The ACDL in Fig. A.7 defines an exception handler aspect, which retries based on the given policy. The exception handler aspect weaves before the outSequence and inSequence in order to enable retrying for errors on the communication between the synapse and external services. A.1.6 The ACDL for Scenario 11 The ACDL in Fig. A.8 defines the secure persisting complex ESB service, which is implemented as a composition of the crypto and persistence aspects. The crypto aspect encrypts the data to be persisted and the persistence aspects saved encrypted data in the database. Figure A.9 illustrates the above scenario graphically.


111



As per Fig. A.9, the pre-processor pipeline consists of the security (crypto) and persistence aspects. The outSequence handovers messages to the preprocessor pipeline which in turn encrypts and saves the messages in a database. After the processing in the pre-processor pipeline completes, the outSequence receives the control again and executes the next Synapse component.

112




A.2 Scenarios 13 and 15 This section presents the resources used in the scenarios from 13 to 15 in the case study.

A.3 Scenarios 14 and 16

113


A.2.1 The Synapse Configuration Figure A.10 shows the synapse configuration shared by the scenarios 13 and 15. In the synapse configuration in Fig. A.10, the main, inSequence and outSequence are similar to the synapse configuration described in Fig. A.1. The sendBackSequence is to be used to send a response back to the client and the calloutSequence is to perform a blocking web service call to an external service. A.2.2 The ACDL for Scenario 13 In the ACDL shown in Fig. A.11, the proxy aspect enables to access the sendBackSequence sequence, which is used to send a response when there is a cache hit for a request. Cache aspect consists with policies for the cache expiration and flushing, and an aspect to be executed for cache hits. It weaves before outSequence and inSequence in order to cache response messages.

A.3 Scenarios 14 and 16 This section presents the resources used in the scenarios from 14 to 16.

114


Fig. A.10. The Synapse Configuration for Scenarios 13 and 15

A.3.1 The Synapse Configuration In the synapse configuration shown in Fig. A.12, the man sequence consists with an in mediator, which executes the sequence named logSequence, which logs a text extracted from a message through an XPath expression. A.3.2 The ACDL for Scenario 14 The ACDL in Fig. A.13 demonstrates the caching of database records. The cache aspect weaves around the persistence aspect. In the persistence aspect

A.3 Scenarios 14 and 16

115


Fig. A.12. The Synapse Configuration for Scenarios 14 and 16

configuration, there is an important parameter named as postAction, which instructs to select the next aspect in the pipeline. The postAction defines the next aspect as the cacheExample along with its operation to be performed as collect, which instructs to load the cache with data. Figure A.14 graphically illustrates above scenario. As per Fig. A.14, the pre-processor pipeline consists with two cache aspects and a single persistence aspect. The cache aspect prior to the persistence aspect is for serving requests from the cache. The cache aspect after the persistence aspect is for loading the cache with the data retrieved through the persistence aspect from a database. The pipeline executes before the logSequence and fills the message with the data, which the logSequence retrieves, and logs.

116



A.4 Scenarios 17 - 22 This section presents the resources used in the scenarios from 17 to 22 in the case study discussed in Sect. 4.2.1. A.4.1 The Synapse Configuration Figure A.15 shows the synapse configuration shared by the samples from 17 to 22. In the synapse configuration shown in Fig. A.15, sequences ep1, ep2, and ep3 are to invoke external services. The main sequence consists with in and out mediator. The in mediator has a reference to the inSequence, which drops requests, and the out mediator has a reference to the outSequence, which sends responses back to the client. A.4.2 The ACDL for Scenario 17 In the ACDL shown in Fig. A.16, there are three proxy aspects, which enable to compose sequences ep1, ep2, and ep3 into the loadbalance as children.


117


The loadbalance aspect composes prior to the inSequence and adds the load balancing behavior. The three children act as loadbalance nodes and the load balancer selects one node based on the load balance algorithm and handover the request in transit to the selected one. Figure A.17 shows the aspect weaving for Fig. A.16. As per Fig. A.17, when the inSequence receives a message, it processes the message through the pre-processor pipeline, within which the loadbalance aspect selects a proxy based on the loadbalance algorithm, and executes the selected proxy with the request in transit. A.4.3 The ACDL for Scenario 18 The basic functionality of the ACDL shown in Fig. A.18 is similar to the ACDL in Fig. A.16. The difference is in the load balance algorithm. This sample uses the dynamic roundrobin, which uses the response time as a parameter to select a node to handover the request in transit. To measure the response time, the monitoring aspect is used, and is weaved prior to the proxies and outSequence. A.4.4 The ACDL for Scenario 20 Figure A.19 shows the ACDL used in the scenario 20 of the case study with Apache Synapse.

118


Fig. A.15. The Synapse Configuration for Scenarios 17 - 22

The aspect weaving for the ACDL shown in Fig. A.19 is similar to the ACDL in Fig. A.16. The only difference is this sample does the session aware load balancing. The session is detected based on the ip address of the client and has an expiration interval as 6000 milliseconds. The load balance algorithm used in the above sample is round robin.




119

120



A.4.5 The ACDL for Scenario 22 Figure A.20 shows the ACDL used in the scenario 22 of the case study with Apache Synapse. The ACDL shown in Fig. A.20 is similar to the ACDL in Fig. A.19. The only difference is in the type of session detecting strategy. This sample uses the HTTP cookies to detect the session.




121

References

1. Chappell,D.: Enterprise Service Bus, Sebastopol. OReilly Media (2004), pp. 1-56 2. Rosen, M., Lublinsky, B., Smith, K. T., Balcer, M. J.: Applied SOA, Indianapolis: Wiley (2008), pp. 342-352 3. Implementing Service Oriented Architecture, SETLabs Briefings, http://www.infosys.com/research/publications/SETLabs-briefingsimplementing-SOA.pdf 4. Sun Microsystems, Java Business Integration (JBI) 1.0, http://jcp.org/en/jsr/detail?id=208 5. Chappell D.: Introducing SCA, http://www.davidchappell.com/articles/ Introducing/ SCA.pdf 6. Apache Synapse Homepage, http://synapse.apache.org/ 7. Woolley, R.: Enterprise Service Bus (ESB) Product Evaluation Comparisons, http://dts.utah.gov/techresearch/researchservices/researchanalysis/resources /esbCompare061018.pdf 8. Bass, L., Clements, P., Kaman R.: Software Architecture in Practice. AddisonWesley Professional, Boston (2003) 9. Ilker, A. N., CetinManaging, S.: Large Scale Reuse across Multiple Software Product Lines. In 10th Conference on Software Reuse. Springer Berlin ,Heidelberg (2008) 10. Beuche, D., Papajewski, H., Schrder-Preikschat, W.: Variability Management with Feature Models. Sci. Comput.Program., 53(3). Elsevier North-Holland, Amsterdam (2004) 11. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J., Irwin, J.: Aspect-Oriented Programming. In 1997 European Conf. on ObjectOriented Programming (ECOOP ’97), pp. 220-242. Springer, Jyvaskyla ( 1997) 12. Josuttis, N.M.: SOA in Practice: The Art of Distributed System Design. OReilly Media, Sebastopol (2007) 13. OASIS Open CSA, http://www.oasis-opencsa.org/sca 14. Clarke. S., Baniassad, E.: Aspect-Oriented Analysis and Design: The Theme Approach.Addison-Wesley Professional, Boston (2005) 15. Buschmann, F., Henney, K., Schmidt, D.C.: Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing. John Wiley and Sons, Chichester (2007)

124

References

16. Piveta, E.K., Zancanella, L.C.: Aspect weaving strategies. Journal of Universal Computer Science 9 (2003) 970983 17. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, Boston (1995) 18. Forgac, M., Kollr, J.: Static and Dynamic Approaches to Weaving. In 5th Slovakian-Hungarian Joint Symposium on Applied Machine Intelligence and Informatics, Poprad (2007) 19. Deursen, A. V., Klint, P., Visser, J.:Domain-specific languages: An annotated bibliography. ACM SIGPLAN Notices, 35(6):2636, New York (2000) 20. Fowler, M.: Language Workbenches: The Killer-App for Domain Specific Languages?, http://martinfowler.com/articles/langua geWorkbench.html 21. Sadjadi, S., McKinley, P.: A survey of adaptive middleware. Technical Report MSU-CSE-03-35. Computer Science and Engineering, Michigan State University, Michigan (2003) 22. McKinley, P. K., Sadjadi, S. M., Kasten, E. P., Cheng, B. H. C.: Composing adaptive software.IEEE Computer, 37(7):5664, Los Alamitos (2004) 23. Clements, P., Northrop, L.: Software Product Lines: Practices and Patterns. Addison-Wesley Professional, Boston (2001) 24. Pohl, K., Bckle, G., Linden, F. J. V. D.: Software Product Line Engineering: Foundations, Principles, and Techniques, Springer, Berlin (2005) 25. Anastasopoulos, M. A. M., Gacek, C. : Implementing product line variabilities. In Symposium on Software Reusability (SSR’01). In Software Engineering Notes 26 (3) 109117, Toronto (2001) 26. Kent, K., Souppaya, M. :Guide to computer security log management.Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology.MD 20899-8930, Gaithersburg (2006) 27. Newton, K.: The Definitive Guide to the Microsoft Enterprise Library, Apress, Berkeley (2007) 28. Hinton, H., Hondo, M., Hutchison, B.: Security Patterns within a ServiceOriented Architecture, http://searchwebservices.techtarget.com /searchWebServices/downloads/SecuritySOA (2).pdf 29. Huang, M., Wang, C., Zhang, L.:Toward a Reusable and Generic Security Aspect Library. In Workshop on AOSD Technology for Application-Level Security (AOSD04), Belgium (2004) 30. Caching Architecture Guide for .NET Framework Applications, http://msdn.microsoft.com/en-us/library/ ms978498.aspx 31. Khan, I.: Distributed Caching and Scalability,http://msdn.microsoft.com/enus/magazine/dd942840.aspx 32. Ross, R. G.: Principles of the Business Rule Approach, Addison-Wesley Professional, Boston (2003), pp. 1-100 33. Luo, Z., Sheth, A., Kochut, K., Miller, J.: Exception Handling in Workflow Systems. Applied Intelligence. vol. 13, no. 2, Kluwer Academic Publishers, Hingham (2000) 34. Gruschka N., Luttenberger, N.: Protecting Web Services from DoS Attacks by SOAP Message Validation. In Proceedings of the IFIP TC- 11 21 International Information Security Conference (SEC 2006), Springer, Boston (2006)

References

125

35. Rashid, A., Chitchyan, R. :Persistence as an aspect. In Proceedings of the 2nd International Conference on Aspect-Oriented Software Development (AOSD 03), pages 120129. ACM Press, New York (2003) 36. ChainBuilder ESB Transaction Support White Paper, http://www.chainforge.net/chainbuilder/CBESB-Transaction-SupportWhitepaper.pdf 37. Walls, C., Breidenbach, R.: Spring in Action Spring in Action, 2nd ed. Manning, Greenwich (2008) 38. J. Poozhikunnel, Enterprise .NET Community: Building an ESB to Support SOA,http://www.theserverside.net/tt/articles/shower ticle.tss?id= BuildingESB 39. Gridipedia, SLA Monitoring and Evaluation,http://www.gridipedia.eu/slamonitoring-evaluation.html 40. Hohpe, G., Woolf, B.: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison Wesley, Boston (2003) 41. Kopparapu, C.: Load Balancing Servers, Firewalls, and Caches. Wiley (2002) 42. Fiorano Software Company, Best practices, Scalability, and Load balancing,http://www.fiorano.com/products/fesb/bestpractices/bestpractices 3.php 43. Bergmans, L., Aksit, M.: Composing Crosscutting Concerns Using Composition Filters. In Communications of ACM, 44(10)51-57, New York (2001) 44. Constantinides, C. A., Bader, A., Elrad, T. H., Netinant, P., Fayad, M. E.: Designing an aspect-oriented framework in an object-oriented environment. In ACM Computing Surveys (CSUR), v.32 n.1es, New York (2000) 45. Loughran, N., Rashid, A.:Mining aspects. In Workshop on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design, In AOSD Satellite workshop, Enschede (2002) 46. Nora, B., Said, G., Fadila, A.: A comparative classification of aspect mining approaches. In Journal of Computer Science 2, 4:322325, 2006 47. Conejero, J. M., Hernandez, J.: Analysis of crosscutting features in software product lines. In Proceedings of the 13th international workshop on Early Aspects, Leipzig (2008) 48. Tekinerdogan, B., Satrolu, Y.:Towards an Aspectual Analysis of Legacy Systems, In 5th Workshop on Object-Oriented Requirements Engineering, Oslo (2004) 49. Colyer, A., Blair, G., Rashid, A.: Managing Complexity in Middleware, In Workshop on Aspect Components and Patterns, Los Alamitos (2003) 50. Zhang, C., Jacobsen, H. A.: Refactoring Middleware with Aspects. In IEEE Transactions on Parallel and Distributed Systems, vol. 14, Los Alamitos (2003) 51. Alves, V., Dantas, A., Borba, P.: AOP-Driven Variability in Product Lines of Pervasive Computing Applications. In Second International Generative Programming and Component Engineering Conference (GPCE’03), Erfurt (2003) 52. Harvey, G., Suesaowaluk, P., Salinas, A.: An Aspect-Oriented Product Line Framework to Support the Development of Software Product Lines of Web Applications. In Proceedings of the 24th South East Asia Regional Computer Conference, Bangkok (2007) 53. Voelter, M., Groher, I.: Product Line Implementation using Aspect-Oriented and Model-Driven Software Development. In Proceedings of the 11th International Software Product Line Conference (SPLC), Kyoto (2007)

126

References

54. Ermagan, V., Krger, I., Menarini, M.: Aspect Oriented Modeling Approach to Define Routing in Enterprise Service Bus Architectures, In Proceedings of the 2008 international workshop on Models in software engineering, 2008 55. Bai, Q. F., Fitch, P. : Delivering Heterogeneous Hydrologic Data services with an Enterprise Service Bus Application. In 18th World IMACS / MODSIM Congress, Cairns (2009) 56. Laddad, R.: AspectJ in action, Manning, Greenwich (2003) 57. MSDN Library, http://msdn.microsoft.com/en-us/library/cc512464.aspx 58. Petals ESB Home Page, http://petals.ow2.org/ 59. OSGI home page, http://www.osgi.org/About/HomePage 60. Aoyama, M, Watanabe, k., Nishio, y., Moriwaki, y.: Embracing Requirements Variety for e-Governments Based on Multiple Product-Lines Frameworks. In 11th IEEE International Requirements Engineering Conference (RE’03). USA ,California (2003) 61. Wijnstra, J.G.: Components, Interfaces and Information Models within a Platform Architecture. In 3rd Conference of Generative and Component Base Engineering .Springer Berlin, Heidelberg (2001) 62. Log4J homepage, http://logging.apache.org/log4j/ 63. Nock, C.:Data Access Patterns: Database Interactions in Object-Oriented Applications, Addison-Wesley Professional, Boston (2003) 64. Ehcache homepage,http://ehcache.org/ 65. Quartz homepage,http://www.opensymphony.com/quartz/ 66. Firebrand Architect,http://www.softwarearchitectures.com/go/Discipline/ DesigningArchitecture/QualityAttributes/tabid/64/Default.aspx 67. Welsh, M., Culler, D., Brewer, E.:SEDA: An architecture for well-conditioned, scalable internet services. In Proceedings of SOSP. pp. 230243, ACM, New York (2001)

Author Profiles

Indika Kumara is a software engineer at WSO2 in Sri Lanaka. He received his BSc in Computer Engineering from University of Moratuwa in 2006 and obtained a MSc in Computer Science from University of Moratuwa in 2010, specializing software architecture. Indika’s experience at WSO2 covers a board range of technical areas including service oriented architecture, enterprise application integration, business rules management, business process management, and complex event processing. He has contributed to the Apache open source projects including Apache Synapse ESB and Axis2 Web Service Engine and got the commitership for both of those projects. His research interests are in the fields of software engineering, service oriented computing, distributed computing, and cloud computing.

Dr Chandana Gamage is a senior lecturer at the University of Moratuwa in Sri Lanka. He is a graduate of the University of Moratuwa where he belonged to the First Batch of Computer Engineering graduates in Sri Lanka. Later he studied at AIT in Thailand for his Masters in Computer Engineering and obtained a PhD in Computer Science from Monash University in Australia specializing in computer network security and cryptography. He has worked in Industry, in Academia and in the Military. A Commissioned Officer in the Sri Lanka Army, Chandana has lived and worked in several countries. Most notably, he has been a computer security specialist at the Free University in Amsterdam in The Netherlands working with the world renowned computer scientist Prof Andy Tanenbaum. His research interests are in the fields of software engineering, cryptography, and computer and network security.

Building ESB Product Lines

Building ESB Product Lines

Suggest Documents

Product Lines that supply other Product Lines: A Service ... - CiteSeerX

Marine Dealer Product Lines

ESB International

Feature Scoping for Product Lines

Refactoring Product Lines - Semantic Scholar

Product Lines of Theorems - People.csail.mit.edu

Building with Lines (web-version)

Building Renovation Product - USLI

ESB template

Ceilings Product Guide - The Building Product Directory

Final Programme - ESB 2014

ESB Contactor.pdf - Google Drive

Introduction to ESB and Petals ESB - CCSL - USP

Product Instantiation in Software Product Lines: A ... - Semantic Scholar

Product Instantiation in Software Product Lines: A Case Study

Improving Decision Making in Software Product Lines Product Plan

Model-Driven Product Consolidation into Software Product Lines

A Study of Product Production in Software Product lines - Defense ...

ESB template

Dynamically Adaptable Software Product Lines ... - Semantic Scholar

Requirements Engineering for Software Product Lines - CiteSeerX

Software Product Lines - Technische Universität Darmstadt

Software Product Lines Essentials - Software Engineering Institute

Tailoring Dynamic Software Product Lines - CiteSeerX