Universal architecture of monitoring ESB compliant with ... - Open ESB

Generic ESB Monitoring Architecture Compliant With JBI

Marek Psiuk Tomasz Bujok

´ Supervisor: Prof. Krzysztof Zielinski

Department of Electrical Engineering, Automatics, Computer Science and Electronics ´ Poland AGH University of Science and Technology, Krakow,

Thesis submitted for the Degree of Master of Computer Science in AGH University of Science and Technology · 2008 ·

Uniwersalna architektura monitoringu ESB zgodna ze specyfikacj¸a JBI

Marek Psiuk Tomasz Bujok

´ Promotor: prof. dr hab. inz. ˙ Krzysztof Zielinski

Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki ´ ´ Polska Akademia Gorniczo Hutnicza, Krakow,

Praca Magisterska ´ Akademia Gorniczno Hutnicza · 2008 ·

”SOA will be used in more than 50 percent of new mission-critical operational applications and business processes designed in 2007 and in more than 80 percent by 2010” Gartner Raport, 2007

Abstract Currently, the significance of the Enterprise Application Integration (EAI) in the field of Service Oriented Architecture (SOA) is gradually increasing. The quality of the integration patterns is constantly ameliorating. Progressive integration solutions are designed, published and offered to the community by most of the prominent IT vendors. Today, Enterprise Service Bus (ESB) is one of the most meaningful solutions and top-selling products on the market of the integration services. There is, however, no agreed-upon definition of what an ESB actually is. Java Business Integration (JBI) presents an approach to standardizing the ESB pattern by specifying a concrete, well-defined and Java-centric model of ESB. The first version of the specification does not mention any kind of monitoring solution for JBI, which is the vital drawback of the concept. Increasing complexity of the SOA-oriented IT systems implies higher importance of the selective monitoring, which allows to mitigate the problem of the management of software infrastructure. The main goal of the thesis is to design and implement a system which adds a monitoring and management logic to a Java Business Integration container in such a way that the logic is fully transparent and compliant with the JBI specification and allows to gather, process and expose sophisticated information regarding the qualitative parameters and operational reliability of the JBI container. The design of the system was performed in accordance with the Experimental Driven Development (EDD) methodology. At the beginning a statement of functional and non-functional requirements was created. Afterwards, an analysis and prototype construction were performed. At the end, the prototype was meticulously examined during a set of experiments which were conducted, in order to provide best-fitting architectural solutions which are compliant with the aforementioned requirements. Finally, it was possible to design and implement functional and innovative realization of the JBI monitoring solution called GlassBus. Performance test have proofed that the average JBI performance deterioration, while being monitored, is not higher than 20 percent. Not only did the results of the work described in this thesis fully satisfy the authors, but they also amazed the academic supervisor. Progressive architectural solutions introduced in GlassBus ensure its forthcoming success.

Contents

Abstract

i

Declaration

ix

Acknowledgements 1

2

Introduction 1.1 Enterprise Application Integration 1.2 Enterprise Service Bus . . . . . . . 1.3 Java Business Integration . . . . . . 1.4 Monitoring . . . . . . . . . . . . . . 1.5 Thesis statement . . . . . . . . . . . 1.6 Research contribution . . . . . . . . 1.7 Organization of thesis . . . . . . .

x

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

1 1 1 2 2 2 2 3

Enterprise Integration Theory 2.1 Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Definition of the Enterprise Application Integration . . . . 2.2.1 Reason for integration . . . . . . . . . . . . . . . . . 2.2.2 Challenge . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Integration taxonomy . . . . . . . . . . . . . . . . . 2.2.4 Integration factors . . . . . . . . . . . . . . . . . . . 2.3 Enterprise Integration Patterns . . . . . . . . . . . . . . . . 2.3.1 Topologies Fundamentals . . . . . . . . . . . . . . . 2.3.2 Integration Fundamentals . . . . . . . . . . . . . . . 2.3.3 Properties of integration solutions . . . . . . . . . . 2.3.4 Point to point Integration . . . . . . . . . . . . . . . 2.3.5 Broker Integration . . . . . . . . . . . . . . . . . . . 2.3.6 Message Bus Integration . . . . . . . . . . . . . . . . 2.3.7 Comparison . . . . . . . . . . . . . . . . . . . . . . . 2.4 Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . 2.4.1 Service Oriented Architecture as ESB environment. 2.4.2 ESB Definition . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

4 4 4 5 6 6 7 8 8 8 9 10 11 16 19 20 21 22

. . . . . . .

. . . . . . .

. . . . . . .

ii

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Contents . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

25 25 26 26 27 32 33 33

JBI Monitoring 3.1 Preamble . . . . . . . . . . . . . . . . . . . . 3.2 Monitoring abstraction . . . . . . . . . . . . 3.3 JBI monitoring status quo . . . . . . . . . . 3.3.1 Monitoring from JSR . . . . . . . . . 3.3.2 ServiceMix monitoring . . . . . . . . 3.3.3 OpenESB monitoring . . . . . . . . . 3.3.4 Clustering . . . . . . . . . . . . . . . 3.3.5 Status quo implications . . . . . . . 3.4 Application monitoring theory . . . . . . . 3.4.1 Application Response Measurement 3.4.2 Business Activity Monitoring . . . . 3.5 JBI Monitoring Challenge . . . . . . . . . . 3.5.1 JBI context influence . . . . . . . . . 3.5.2 Application theory influence . . . . 3.6 Conclusion . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

35 35 35 37 37 39 41 45 49 50 50 55 59 59 61 64

Executive summary of the monitoring architecture 4.1 Preamble . . . . . . . . . . . . . . . . . . . . . . 4.2 Problem definition . . . . . . . . . . . . . . . . 4.2.1 Non-functional requirements . . . . . . 4.2.2 Functional requirements . . . . . . . . . 4.3 Introducing GlassBus . . . . . . . . . . . . . . . 4.4 Monitoring Abstraction . . . . . . . . . . . . . 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

66 66 66 67 69 71 72 77

GlassBus Research 5.1 Preamble . . . . . . . . . . . . . . . 5.2 Experiments placement . . . . . . . 5.3 Information acquiring mechanism 5.3.1 Possible options . . . . . . . 5.3.2 Realisation . . . . . . . . . . 5.4 JBI monitoring mechanisms . . . . 5.4.1 Monitoring information . . 5.5 Correlation heuristics . . . . . . . . 5.5.1 Problem definition . . . . . 5.5.2 Realization . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

79 79 80 81 81 82 83 83 87 88 89

2.5

2.6 3

4

5

2.4.3 ESB implementations . 2.4.4 Summary . . . . . . . Java Business Integration . . . 2.5.1 Background . . . . . . 2.5.2 Architecture . . . . . . 2.5.3 JBI Implementations . 2.5.4 Summary . . . . . . . Conclusion . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . .

. . . . . . . .

. . . . . . . . . .

. . . . . . . .

. . . . . . . . . . iii

. . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Contents 5.6

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

94 95 96 99 99 103 110 112 116 117 117 118 120 120 121 122 122 123 125 126 126 127 128 129 130 131

GlassBus Implementation 6.1 Preamble . . . . . . . . . . . . . . . . . . . . 6.2 Architecture Overview . . . . . . . . . . . . 6.3 Logical Structure . . . . . . . . . . . . . . . 6.3.1 Domain model . . . . . . . . . . . . 6.3.2 GlassBus Agent . . . . . . . . . . . . 6.3.3 GlassBus Engine . . . . . . . . . . . 6.3.4 External interface model . . . . . . . 6.3.5 Management and selectivity model 6.3.6 Invocation flows . . . . . . . . . . . 6.4 Physical Structure . . . . . . . . . . . . . . . 6.5 Configuration . . . . . . . . . . . . . . . . . 6.6 Installation . . . . . . . . . . . . . . . . . . . 6.7 Implementation status . . . . . . . . . . . . 6.8 Performance Tests . . . . . . . . . . . . . . . 6.8.1 Test environment . . . . . . . . . . . 6.8.2 ServiceMix . . . . . . . . . . . . . . . 6.8.3 OpenESB . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

133 133 134 136 136 140 143 144 150 152 155 157 159 160 160 161 162 163

5.7

5.8

5.9

5.10

5.11

5.12

5.13 6

Persistence . . . . . . . . . . . . . . . . . 5.6.1 Database choice . . . . . . . . . . 5.6.2 Persistence abstraction . . . . . . Communication middleware . . . . . . 5.7.1 Communication theory . . . . . 5.7.2 MOM Implementation provider 5.7.3 JMS Sender . . . . . . . . . . . . 5.7.4 JMS Receiver . . . . . . . . . . . 5.7.5 Communication security . . . . . Management middleware . . . . . . . . 5.8.1 Possible options . . . . . . . . . . 5.8.2 Realisation . . . . . . . . . . . . . Hierarchical Data Management . . . . . 5.9.1 Possible solutions . . . . . . . . . 5.9.2 Realization . . . . . . . . . . . . . Installation and runtime environments . 5.10.1 Deployment assumptions . . . . 5.10.2 Deployment scenarios . . . . . . 5.10.3 Realization . . . . . . . . . . . . . Monitoring interface . . . . . . . . . . . 5.11.1 Possible solutions . . . . . . . . . 5.11.2 Realization . . . . . . . . . . . . . Logging . . . . . . . . . . . . . . . . . . . 5.12.1 Possible options . . . . . . . . . . 5.12.2 Realization . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . .

iv

. . . . . . . . . . . . . . . . . . . . . . . . . .

Contents

6.9 7

6.8.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Conclusions 7.1 Overview . . . . . . . . . . . . . . . . . 7.2 The status of Java Business Integration 7.3 Future of JSR-208 - JBI 2.0 . . . . . . . 7.4 GlassBus achievement . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

166 166 167 167 169

Appendices

171

A Source code

172

Bibliography

186

v

List of Figures

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12

Integration scopes . . . . . . . . . . . Point to point integration . . . . . . . Broker integration . . . . . . . . . . . Classes of brokers . . . . . . . . . . . Direct Broker Sequence Diagram . . Indirect Broker Sequence Diagram . Bus integration . . . . . . . . . . . . Topology Summary . . . . . . . . . . Location of ESB in SOA environment Architecture of JBI . . . . . . . . . . . JBI Messaging Model . . . . . . . . . Message Exchange Flow . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

6 10 12 13 14 14 16 19 21 27 28 31

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10

ServiceMix clustering . . . . . . . . . . . . . . . . . OpenESB clustering . . . . . . . . . . . . . . . . . . Application invokes methods on ArmTransaction Connection between ARM Interface and Agent . . Sample distributed system . . . . . . . . . . . . . . Transaction and parent-child correlators . . . . . . Message Oriented Middleware ARM patterns . . Business process management life-cycle . . . . . . CEP-oriented BAM architecture . . . . . . . . . . . Possible Architecture Positioning . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

46 48 51 51 52 52 53 56 63 64

4.1 4.2 4.3 4.4 4.5 4.6

GlassBus architecture overview . . . ME FLOW PATTERN example . . . ME SUB FLOW PATTERN example ME TRANS example nr.1 . . . . . . ME TRANS example nr.2 . . . . . . BUSS TRANS PATTERN example .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

72 74 74 75 76 77

5.1

GlassBus architecture overview - placement of the experiments . . . . . . . . . . .

80

. . . . . .

. . . . . . . . . . . .

. . . . . .

vi

. . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . .

. . . . . .

List of Figures 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9

Message correlation algorithm overview . . . . ActiveMQ Broker Topology . . . . . . . . . . . Out-of-the-box scenario . . . . . . . . . . . . . Distributed scenario . . . . . . . . . . . . . . . Engine broker clustering . . . . . . . . . . . . . Message Driven Pojos architecture . . . . . . . GlassBus deployment to Single monolithic bus GlassBus single out-of-the-box deployment . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

90 104 108 109 110 113 123 124

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15

GlassBus complete architecture . . . . . . . . . . . . . . General logical structure . . . . . . . . . . . . . . . . . . JBI Topology . . . . . . . . . . . . . . . . . . . . . . . . . JBI Message Exchange Patterns . . . . . . . . . . . . . . GlassBus Dao . . . . . . . . . . . . . . . . . . . . . . . . GlassBus Agent . . . . . . . . . . . . . . . . . . . . . . . GlassBus Engine . . . . . . . . . . . . . . . . . . . . . . . External monitoring interface . . . . . . . . . . . . . . . The Agent in the Engine registration sequence diagram Messaging propagation sequence diagram . . . . . . . Topology propagation sequence diagram . . . . . . . . Physical structure of GlassBus implementation . . . . . ServiceMix topology for performance tests . . . . . . . OpenESB topology for performance tests . . . . . . . . Comparison of GlassBus performance overhead . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

135 136 137 138 140 141 143 146 153 154 155 156 162 163 164

vii

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

List of Tables

2.1 2.2

Topologies comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . JBI implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20 32

3.1 3.2 3.3

Clustering comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . JBI implementations comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abstraction contextual evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49 49 61

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17

AOP Requirement compliance . . . . . . . . . . . . . . . . . . . . . . JBI parameters requirement compliance . . . . . . . . . . . . . . . . . JBI parameters requirement compliance . . . . . . . . . . . . . . . . . Persistence Requirement compliance . . . . . . . . . . . . . . . . . . . Tight vs. Loose coupling discussion . . . . . . . . . . . . . . . . . . . Communication middleware comparison . . . . . . . . . . . . . . . . Basic comparison of the middleware performance . . . . . . . . . . . ActiveMQ performance comparison - embedded brokers . . . . . . . ActiveMQ performance comparison - embedded and remote brokers JMS sender performance comparison . . . . . . . . . . . . . . . . . . . JMS transmission reliability . . . . . . . . . . . . . . . . . . . . . . . . Communication middleware - requirement compliance . . . . . . . . Management requirement compliance . . . . . . . . . . . . . . . . . . Hierarchical data - requirement compliance . . . . . . . . . . . . . . . Deployment Requirement compliance . . . . . . . . . . . . . . . . . . Monitoring interface - requirement compliance . . . . . . . . . . . . . Logging Requirement compliance . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

83 87 94 99 101 102 103 107 108 111 114 116 119 122 126 128 131

6.1 6.2 6.3 6.4 6.5

Timing path - MEP relations . . . . Performance of glazed ServiceMix GlassBus overhead in ServiceMix . Performance of glazed OpenESB . GlassBus overhead in OpenESB . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

139 162 163 163 163

7.1 7.2

GlassBus effort perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Proof-of-Concept projects effort perspective . . . . . . . . . . . . . . . . . . . . . . . 169

. . . . .

. . . . .

. . . . .

. . . . .

viii

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Declaration

The work in this thesis is based on the research carried out at the Department of Electrical Engineering, Automatics, Computer Science and Electronics of the AGH University of Science and ´ Poland. No part of this thesis has been submitted elsewhere for any other Technology in Krakow, degree or qualification and it is all our own work unless referenced to the contrary in the text. It has to be admitted that all work enclosed in the thesis is the result of a joint and collective research conducted and approved by both of the authors. Organization of the thesis as well as the outline and content of the chapters were also agreed upon. It has to be mentioned, however, which part of the text describing the aforementioned research, is the individual contribution of each author: • Tomasz Bujok wrote Chapters 1, 2, 4 and the following Sections of Chapter 5 : 5.1, 5.2, 5.5 (without 5.5.2), 5.7, 5.9, 5.11. • Marek Psiuk wrote Chapters 3, 6, 7 and the following Sections of Chapter 5 : 5.3, 5.4, 5.5.2, 5.6, 5.8, 5.10, 5.12, 5.13.

c 2008 by Tomasz Bujok and Marek Psiuk. Copyright “The copyright of this thesis rests with the authors. No quotations from it should be published without the authors’ prior written consent and information derived from it should be acknowledged”.

ix

Acknowledgments

First of all, we would like to express our sincere gratitude and appreciation to our thesis advisor, ´ Prof. Krzysztof Zielinski, for his continuous inspiration, encouragement, patience and careful guidance during our study years. He gave us the opportunity to minutely consider the problems of IT and he taught us how to meticulously analyze them from different perspectives. He has also shown a great and consistent interest in our project during its design and development which greatly refined its quality. We would also like to thank our families for the guidance, support and love they provided us with in particular through the work on the thesis, without whom we would not have finished. In conclusion, we would like to express our gratitude to Magdalena Gawłowska-Bujok and Katarzyna Hussar for an indispensable and thorough proofreading.

Tomasz Bujok, Marek Psiuk ´ Poland Krakow, September 9, 2008

x

Chapter 1

Introduction We are what we repeatedly do. Excellence, then, is not an act, but a habit. Aristotle, Ancient Greek Philosopher, Scientist and Physician. This chapter briefly introduces the basic terms and concepts of the Enterprise Application Integration, Enterprise Service Bus as well as Java Business Integration. It also explains the importance of monitoring, which is a key aspect of every modern enterprise system. This chapter also presents the goals and main assumptions of the thesis.

1.1

Enterprise Application Integration

Today, enterprises are facing numerous challenging problems induced by development of the global village and the Internet itself. On the one hand, company customers constantly demand real-time service, better performance, higher quality and lower prices. On the other hand, the market is constantly undergoing dynamic changes to which companies have to react, which creates competitive growth. The strategy of sustainable development makes the companies become more agile in the sense of ability to react to the requirements that rapidly alter and demands of the environment. One of the most important relations which have to be shaped by an efficiently operated company, whose quality cannot deteriorate during the organization’s evolution, are: • B2B - Business to Business - a set of relations between specified business and cooperating businesses. • B2C - Business to Consumer - a set of relations between specified business and a consumer. Business agility is mostly dependent on business infrastructure. In addition, the infrastructure determines the agility of the business as this very infrastructure has to provide the company with the possibility of implementing new business processes through the integration and cooperation between existing ones. All these modifications have to be implemented as fast and efficiently as possible, which reduces business costs. The explained process of Enterprise Integration has to be performed at the level of computer applications which is a core of every modern organization.

1.2

Enterprise Service Bus

”In computing, an enterprise service bus (ESB) refers to a software architecture construct. This construct is typically implemented by technologies found in a category of middleware infrastructure products, usually based on recognized standards which provide fundamental services for more complex architectures via an event-driven and standards-based messaging engine (the

1.3. Java Business Integration

2

bus)” [1]. What is very interesting, this definition of ESB by Wikipedia is only one of the wide variety of explanations. There is no agreement on what ESB actually is in the enterprise community. The majority says that it is an Enterprise Application Integration instrument. All of these matters mentioned here are thoroughly investigated in what follows.

1.3

Java Business Integration

Java Business Integration (JBI) [2] is a formal specification developed under the Java Community Proces (JCP) [3]. The first version (1.0) was released on the 17th of August 2005 and is referenced by the Java Specification Request numbered 208 (JSR-208) [2]. The second version (2.0), referenced by JSR-312 [4], was supposed to be released in the second quarter of 2008 but is already late. The main goal of JBI is to address the problems of Enterprise Application Integration and businesstwo-business solutions (B2B). JBI is an implementation of the ESB integration mechanism.

1.4

Monitoring

Increasing complexity of IT systems, in particular enterprise solutions, implies higher importance of monitoring and management, which allows to mitigate the problem. Authors of Java Business Integration were aware of these facts since the specification introduces advanced management mechanisms in the sixth chapter of the JSR-208. However, it has to be admitted that the monitoring mechanisms introduced in the specification are rather basic and do not provide sophisticated functions. Therefore, great prospects are opened for the enhancements of the monitoring capabilities of JBI.

1.5

Thesis statement

The main goal of the thesis is to state that the design and implementation of a generic and reusable monitoring architecture which is complaint with JBI is possible and beneficial for the JBI communities. Thesis statement that formalizes aforementioned matter, reads as follows: There exists a processing model which enables the construction of a system which adds a monitoring and management logic to a Java Business Integration container in such a way that the logic is fully transparent and compliant with the JBI specification and allows to gather, process and expose sophisticated information regarding the qualitative parameters and operational reliability of the JBI container. This dissertation presents the mentioned model as well as its implementation and experimental verification. Target implementations of the JBI-compliant runtime environment used during the verification are: OpenESB1 and ServiceMix2 .

1.6

Research contribution

The essential contributions of the presented thesis read as follows: 1 https://open-esb.dev.java.net/ 2 http://servicemix.apache.org/

1.7. Organization of thesis

3

• Theoretical model - general assumptions on the transparent JBI monitoring model based on the Aspect Oriented Programming3 and Message Oriented Middleware3 . Theoretical approach is also based on Application Response Measurement3 as well as Business Application Monitoring3 . • Concrete architecture - specification of a concrete JBI monitoring architecture based on the aforementioned theoretical model. • Proof of concept - implementation of the JBI monitoring mechanism based on the concrete architecture. • Evaluation - performance and usability tests run in distributed JBI environment.

1.7

Organization of thesis

This thesis is organized in the following way: • Chapter 2 overviews the existing application integration technologies presenting complete background of ESB and JBI technologies. At the end, precise definition of these concepts is presented in order to provide a clear view of the domain of the thesis. • Chapter 3 examines the taxonomy of monitoring systems. It also contains the status quo of the JBI monitoring on the basis of JSR-208 specification as well as OpenESB and SerivceMix proprietary solutions. At the end, an overview of some helpful monitoring solutions is provided. • Chapter 4 presents the executive summary of the monitoring architecture in form of the functional and non-functional requirements. It also thoroughly explains the notions and concepts introduced by the final solution - called GlassBus. • Chapter 5 concisely formulates the results of experimental driven development carried out in order to choose the best fitting architectural solutions for GlassBus. • Chapter 6 describes the architecture and implementation of GlassBus. It forms a complete development documentation of the project. Results of the performance tests are enclosed at the end of the chapter. • Chapter 7 summarizes the conclusions and reflections concerning final solution and future works in the field of JBI.

3 The

concept is precisely explained in the following chapters.

Chapter 2

Enterprise Integration Theory ”Always design a thing by considering it in its next larger context a chair in a room, a room in a house, a house in an environment, an environment in a city plan.” Eliel Saarinen, a Finnish-American architect and city planner.

2.1

Preamble

The main goal of this chapter is to meticulously outline the domain of the thesis. At the beginning, the general idea of Enterprise Application Integration is presented. The section contains an explanation of integration reasons, challenges as well as integration taxonomy which helps to summarize all factors regarding application integration. The main emphasis is put on the importance and complexity of the discussed issue. Next section contains the integration fundamentals in form of the integration patterns which state the building bricks of every integration technology. Two core patterns of mediation and federation are explained. At the end, common properties and characteristics of every integration solution are identified and described. Discussed problem is explicated in the next section as three main integration patterns are described. These are: Point-to-point integration, Broker integration and Bus integration. Every pattern is carefully investigated. Explanations are supplemented with diagrams which present topology of each solution. At the end, advantages and disadvantages are thoroughly discussed, pointing the crucial differences between patterns. The core part of this chapter is dedicated to explaining the concepts of Enterprise Service Bus as well as Java Business Integration. These are the most interesting technologies, since they compose the exact environment of the desired monitoring solution. Both definitions are of crucial importance as there is much misunderstanding of these concepts - no only in the Internet but also in the IT community. Therefore, proper explanation is the key to accurate formulation of borders between the system and environment.

2.2

Definition of the Enterprise Application Integration

The description of the EAI presented in the first chapter (1.1) can be brightly summarized by this single sentence: ”EAI is the soluble glue needed for modular relationships that allow organizations to be flexible and responsive to market demands.” [84] The commonly used term refers to the modernization, consolidation and coordination of the applications in an enterprise [5]. According to one of the Gartner reports, [84] the EAI is the ”unrestricted sharing of data and business processes among any connected application or data sources in the enterprise”. EAI can be also introduced as ”the uses of software and computer systems architectural principles to integrate a set of enterprise computer applications.” [6]

2.2. Definition of the Enterprise Application Integration

2.2.1

5

Reason for integration

Huge enterprises typically consist of hundreds of applications that are proprietary-built, obtained from a third-party, part of a legacy system, operating in multiple tiers, operating systems, platforms and localizations. An enterprise that comprises thirty different web sites, three instances of SAP and countless departmental solutions is commonly seen. There are many reasons for the fine granularity of contemporary enterprise applications: • Design complexity - writing business applications poses great difficulties. Creating a single, monolithic, extendible and easily manageable application to run a complete business enterprise is almost impossible. • Software age - it is not very common that all applications used in an enterprise are written at the same point of time. They are being increasingly added during the growth of an enterprise. • Technologies - some of the enterprise applications are designed using wide variety of specified, different technologies, as it was the general architectural recommendation at the current stage. • Legacy solutions - are present in many enterprises. These are the applications with unavailable source code, no support, no documentation or which are simply too expensive to be redesigned. • Local requirements - distributing business functions and business operations across multiple applications provides an enterprise with flexibility to select the best fitting option at the specified situation. • Control - sometimes it is easier to have all administrative tasks done locally in every single application as it improves local accountability. • Better performance - fine granularity gives the possibility to tune the underlying hardware specially for the needs of the installed pieces of software. • Bad design - application are written ad-hoc without performing adequate research. • Unknown scope - current integration goals were unknown at the specified application design stage. On the one hand, users such as customers or business partners which interact with the frontend application do not generally think about the system boundaries and limitations when they inter-operate with a business. They simply want to execute business functions and get the expected results regardless of the count and complexity of internal systems that the business consists of. The view of an enterprise has to be unified, simple and functional to the customer. On the other hand, every single application requires specified amount of autonomy which provides developers with space for innovation, improvisation and improvements. Without these elements, when application resides in rigidly integrated, rigorous environment, it could quickly become unprofitable and, in the end, dead. Therefore, there is a strong and urgent need for enterprise application integration patterns which cope with all aforementioned aspects which specify successful and well-considered integration solutions.


2.2.2

6

Challenge

During the previous years some of the traditional ways of performing the Enterprise Integration have failed, some have shown that the process has to be investigated and improved further on. The most important aspect of the EAI is the way how it is performed. It should be straightforward, standardized, manageable and cheap. According to [82] there is much work to be done in this field: ”Integration of information systems is expensive and time consuming. Between 20% and 40% of labor costs can be traced to the storage and reconciliation of data. In addition, 70% of code in corporate software systems is dedicated to moving data from system to system.” One of the reports [7] claims that: ”A well-designed integration infrastructure will enable businesses to become more adaptive in their business processes, while reducing information latency and business cycle times. New, standards-based integration technology is driving down the cost of application integration by approximately 50%.” All facts and numbers show the importance of the properly performed EAI.

2.2.3

Integration taxonomy

Enterprise Integration can be considered and performed on different scopes. Please see Figure 2.1 and explanation below which present the crucial technical aspects of enterprise integration [82].

Figure 2.1: Integration scopes1

• Requirements and principles - determine the functional and non-functional requirements of the integrated enterprise. Use-case modeling is one of the ways of achieving this step. • Business integration - determines and integrates business processes which span across multiple applications. Business process re-engineering (BPR) is often performed at this stage. 1 Figure

downloaded from [82].


7

• Presentation integration - deals with the creation of the consistent and unified view of the enterprise providing single front-end application. Main users are: employees, customers, partners, and suppliers. • Data integration - ensures that all applications ”understand” the data format used in cooperating applications. Data modeling consists of: normalization, integration and consistency of data. • Control integration - deals with different types of communication between applications. Determines the messaging models and protocols. • Connectivity - investigates communication protocols which are used in the applications. Ensures the inter-connectivity between applications. • Quality attributes - Put emphasis on the quality attributes of the integrated application and ensures that the business requirements are translated into quality attributes. • Application integration - is the main goal, spans all the layers of the integration model. Ensures that all different applications finally work together.

2.2.4

Integration factors

Companies that want to avoid drawbacks and pitfalls during and after the integration, face many challenges while choosing the proper integration solution. What is obvious, two main options are: build or buy. There are many factors on the basis of which the decision should be taken. The list presented below outlines some of the most important ones. • Quality - What is the quality of the solution? Does it fulfill all the functional and nonfunctional requirements? • Cost - What is the total cost of the solution? What is the cost to quality factor? • Effectiveness - What is the effectiveness and efficiency of the solution? • Speed - How long does it take to integrate? How many people have to be involved? • Complexity - How complex is the integration solution? Is it based on open standards or proprietary solutions? Is it well documented? • Flexibility - What is the nature of the integration? Is the integrated system difficult to modify? What is the time to react to the specified problems known a-priori? Are the elements tightly coupled? The list is not complete, but it briefly shows the problems that every company has to face during consideration of integration. As stated here [7], two main factors are cost and speed. Companies have to think strategically and tactically, putting more emphasis on the integration architecture and usage of open-standards which are easier to learn and faster to use. Companies should make an assumption that a product will be replaced in two years, which greatly influences the price negotiations.

2.3. Enterprise Integration Patterns

2.3

8

Enterprise Integration Patterns

Enterprise Integration Patterns are simply widely known design patterns which tell how and using which building bricks the integration should be performed. They are the set of reusable rules and solutions to commonly known problems occurring during the integration. A great set of enterprise integration patterns is presented in the book ”Enterprise Integration Patterns” by Gregor Hohpe and Bobby Woolf [88]. Right now, the most important integration patterns will be discussed.

2.3.1

Topologies Fundamentals

Topology defines an arrangement of elements. When discussing the topology of an enterprise system we can easily notice two kinds of elements: • hardware artifacts - physical components of the computer system. • software artifacts - a set of computer programs and applications. We can also distinguish two levels of abstractions: • physical level - describes the way that each hardware artifact physically connects to the network. It also describes the means, the sequence, and the protocol that hardware artifact uses to communicate. • logical level - describes the arrangement of channels, collaborations, and mechanisms that different software artifacts residing on hardware artifacts use to interoperate. The subject-matter of this thesis focuses only on the logical level, discussing the paradigms and design patterns that different software artifacts implement to make the whole topology interoperable.

2.3.2

Integration Fundamentals

According to this definition [6] there are two main integration foundations which all other integration patterns derive from. These are: • Mediation; • Federation; Mediation Mediation pattern or mediator pattern is one of the behavioral design patterns described in the book by ”Gang of Four” [83]. It is a software design pattern that specifies an unified mediator element with a commonly known interface which acts as a intermediary. Elements of the system do not interact with each other. They communicate through the mediator which encapsulates the mediation logic instead.


9

Federation There are numerous unclear opinions about the popular federation pattern. Some people call it a facade, the others - a federation. There is, however, a clear difference between these two patterns. Facade is a software design pattern that provides a unified interface to a system, for example, to reduce the dependencies or wrap a poorly written APIs with a single well-designed API. A federation pattern is a more abstract integration pattern which defines interoperation between systems or applications. If a set of systems provides the same functions and can interoperate forming one system that provides the the same functions as the constituent systems, then architecture is based on the federation pattern. Federations are main means which provide systems with scalability. There are two types of federations [8]: • ”homogeneous federations - composed of like subsystems with at least the same interfaces and usually the same implementations and exposing the same interface for the composed system”; • ”heterogeneous federations - where some amount of mediation is required to coerce some subsystem”; The confusing misunderstanding is probably caused by the Data Federation Pattern [9] that addresses the data integration problem. It has a similar approach to a ”facade” pattern in object programming while having the word ”federation” in its name.

2.3.3

Properties of integration solutions

Whenever application integration is considered there are many common architectural elements (later called integration services), regardless of specified integration pattern. Data transformation and connectivity are the aforementioned pieces of critical importance. The list presented below, based on article by Microsoft Press [10], tries to summarize all of these common aspects. • Messaging (Routing) - Core of the integration system. It supports data reconciliation, transformation and routing among integrated applications. • Adapters and Connectors (Transformation) - Elements which create an abstraction layer for the transfer and data protocols. It is an extendible framework which supports connectivity to all of the specified applications. • Supporting Platform - Services to support cooperation of application regardless of hardware and software platform. • Management and Administration (Registration) - Services to support deployment of artifacts, monitoring and runtime management of the integrated system. • Security - Provides authentication and authorization mechanisms, like single sign-on2 . • Monitoring for B2B Processes - Services whose main goal is to monitor the business transactions that are executed in the integrated system. Monitoring consists of status activity monitoring and failure monitoring. 2 http://en.wikipedia.org/wiki/Single

sign-on


10

• Business Process Management - ”If business-to-business transactions are to be automated through the exchange of messages and documents, it is necessary for an EI platform to provide a set of support functions for these document exchanges, such as receipts and acknowledgments, activity status monitoring, failure or out-of-process alerts, and compensatory events. This feature set is one of the most important to consider when differentiating truly comprehensive EI platforms.” [10]

2.3.4

Point to point Integration

This is the first and most intuitive pattern or anti-pattern which began to gain a bad reputation in the last decade. It mainly represents the build approach which was mentioned earlier. The general rule is that during implementation companies write custom, point-to-point interfaces and facades in order to perform the integration of specified applications. P2P topology is presented in Figure 2.2.

Figure 2.2: Point to point integration3

It derives from mesh networks where every node can connect to each other. Mesh networks can be classified for example into the group of ad-hoc networks, like for example MANET. It was introduced on the battle-fields in the army, when a data transmission among mobile nodes without any other infrastructure was urgently required. The fact that there was no need for any kind of mediation between the nodes was most important. They used exactly the same transmission protocol and data format, thus all the nodes could connect to each other without additional activities. This assumption is not correct with the reference to the application integration. Since the general purpose is completely different, it is quite obvious that it is hard to expect that all features will be beneficial. In an enterprise application usually uses different data formats and transfer protocols. It results in the fact that whenever an application requires a connection with another applications, all aspects of integration, like data reconciliation and transfer protocol unification, have to be hard-coded in the integration code. The repeated process is the major drawback of the point-to-point integration pattern. It leads very soon to the commonly known ”n squared” problem, which means that there 3 Figure



11

are at most ”n squared” connections among applications. Any kind of addition of new application results in at most ”n” new connections and interfaces, which actually causes additional costs. This kind of topology, known as ”Big ball of mud” [12], appears to have no distinguishable architecture, it is hard to manage and code reusability is poor. Summarized list of the point-to-point features is presented below. Advantages: • Simplest approach, quickest option for small enterprises; • Minimizes the data transfer time as the connection is direct; • Provides redundancy of connection paths (multi-hop connections), in case of direct connection failure; • Graph theory can be applied to the path management; Disadvantages: • Integration anti-pattern; • Addition of new system results in at most ”n” new connections and integration interfaces; • Unmanageable in big systems with ”n squared” connections; • Proprietary integration code is duplicated and it is difficult to maintain, to extend, to test, and to manage; • Does not scale at all (”Big ball of mud” architecture), good only for small systems; • Implements neither federation nor mediation pattern. Mediation interfaces are hard coded in every application; It is very hard to say that the point to point integration pattern is bad, and all the other patterns are good. However, when rating the solution according to the criteria introduced in Chapter 2.3.3 the result is very poor. Every aforementioned integration service has to be implemented as the proprietary solution, which is expensive, hard to manage and, in most cases, unreusable. P2P integration is successfully applied in small enterprises with not many applications and connections but the integrator has to be aware of the main pros and cons during the integration in order to choose the best fitting solution.

2.3.5

Broker Integration

Broker integration pattern was invented to fill the gap created by the P2P integration. P2P solutions were beneficial for small enterprises where the number of application was minimal and all connections were nonvolatile and commonly known. However, when the companies faced growth problems, P2P became inefficient, expensive and unmanageable. Therefore, broker integration pattern was introduced.


12

Figure 2.3: Broker integration4

Pattern presented in Figure 2.3 introduces the definition of centralized integration broker which links the applications. The main goal of a broker is to decouple source systems from target systems by assuming responsibility for interoperability and coordination of communication. All integration services are incorporated into the central broker which acts as a intermediary among applications. It is located in the center of the system, between the source and target applications. Usually the whole process of communication goes through the broker. Thanks to the centralized configuration, there is a reduced number of connections which come to ”n” where ”n” is the number of systems. It is a great improvement in comparison to P2P topology with ”n squared” connections. When an application is added to the enterprise system, integration with only one element - central broker has to be performed. During this process the integrator has a wide variety of integration services residing in the broker, thus there is no need to write the whole integration code. However, there are also drawbacks. The broker is a single point of failure, which means that when it is down, the whole system is down. The problem can be resolved by clustering the central machine on which broker resides, but such scalability is limited to the scalability of this machine. What is obvious, the advantages of the centralized topology automatically entails disadvantages which come out of the general rule of this topology. There are three main classes of brokers[13] (Figure 2.4): • Direct brokers; • Indirect brokers; • Message brokers; 4 Figure



13

Figure 2.4: Classes of brokers5

Direct Broker Its main distinctive characteristic is the way in which it coordinates communication. After establishing the initial communication, the two parties communicate directly (without the mediation of the broker) using specified proxies. Figure 2.5 which is presented below depicts sequence of invocations: 5 Figure



14

Figure 2.5: Direct Broker Sequence Diagram6

Indirect Broker Indirect broker coordinates the communication differently. It is especially useful when a careful control over the communication is required. Figure 2.6 which is presented below depicts sequence of invocations:

Figure 2.6: Indirect Broker Sequence Diagram6 6 Figure



15

Message Broker aka. Hub and Spoke The hub and spoke distribution paradigm has been known for many years. It is a implementation of a star-network topology. It also derives from American airline industry. In 1955 [14] Delta Airlines pioneered the spoke-hub model at its hub in Atlanta, reducing the usage of point to point model. At the beginning only direct flights, operated by the middle size airplanes, were scheduled. Later, model started to alter and direct flights were replaced by hub-to-hub flights, operated by huge airplanes and local spoke-to-hub flights. In 1978 this model was annexed by several airlines and it has been widely used until nowadays. The main idea is the reduction of connections, which leads to more efficient use of transportation resources. While this example is connected with the airline industry, a few advantages are simply observable in reference with the enterprise integration. Coming back to the IT field, a message broker, also referred to as a hub and spoke, is the specialized version of the broker pattern. It uses message oriented middleware (MOM) as the communication platform where messages are the information carrier. The most important fact here is that the message broker can expose different interfaces. It does not enforce the usage of the agreed-upon unified data format. To receive the messages, application have to register themselves in the broker using the specified mechanism. Main responsibilities of the message broker [15]: • Receiving messages; • Determining recipients and performing the routing; • Handling transformation; • Sending a message to the recipients; Broker summary Summarized list of the broker features is presented below. Advantages: • Clear structure - implements the mediation pattern. • Simplicity - reduces the number of connections among applications. New application has to be integrated only with the hub which deals with the data unification, communication and translation. • Centralization - provides flexibility and centralizes the configuration. Single point of configuration modifications. • Services - provides a set of implemented integration services which are used during the integration. No proprietary spaghetti code has to be written. • Convenience - topology is more intuitive. Management and monitoring is convenient.


16

Disadvantages: • Single point of failure - when the broker is down, the enterprise is down. • Congestion point - performance of the system is mainly dependent on the performance of the broker. It can be a bottleneck. • Complex proprietary solution - brokers are usually heavy, ”all-in-one” proprietary solutions based on closed, corporate standards, which makes them very complex to understand and use. Using such solutions indicates in many cases hiring a third-party, consulting company which performs integration and trains developers and stuff how to use the corporate broker. Undoubtedly, it generates high costs. Broker pattern solved the ”n squared” problem caused by P2P unstructured integration. Pattern is successfully implemented and brought into the real business. Main implementations are licensed, proprietary, vendor-dependent solutions, which are very expensive. The utilization of the technology cannot be done ad-hoc as the level of complexity is very high, which also increases the integration costs. Work force costs are also worth mentioning as it takes a lot of time to get acquainted with all vendor-specific solutions.

2.3.6

Message Bus Integration

The term bus derives from computer networking as well as from computer architectures. In a bus network a set of nodes is connected using a shared communication line - the bus. In computer architecture a bus is a subsystem which is responsible for transferring the data between computer components. Unlike the point-to-point connection, a bus can logically connect a set of nodes using the same shared communication line. Normally, each bus specifies a set of connectors to plug the elements. The idea, which is very intuitive and straightforward, is depicted in Figure 2.7.

Figure 2.7: Bus integration7

Let’s take a closer look at the bus architecture, being more precise at the message bus, since it is the implementation of the bus paradigm in the application integration field. The general purpose 7 Figure



17

is to enable applications to work together in a decoupled manner, so that the applications can be plugged in and out without affecting the behavior of others. Message bus behaves as the message broker between plugged applications. It automatically reduces the number of point-topoint connections as the only connection which an application has to initiate, is the link with the bus. Message Bus is a combination of: • common description language; • common command set; • messaging infrastructure; which allows different systems to interoperate using a specified set of well-known interfaces. The main idea of the bus integration is based on the agreed-upon common description language (CDL) which could be understood by all parts of the system. It is a layer of abstraction. Whenever an application has to be plugged into the bus, there are certain steps to follow: • describe the data in the CDL format; • describe the services in the CDL format; When an application wants to use another application, it simply sends messages to the bus using the common command set. Prepared messages have to comply with the specified format which the bus expects (CDL). Invocation arguments as well as the invocation results are also described using the CDL, so the interoperability is provided. Messaging infrastructure provides the application with the possibility to communicate in a reliable and robust way. Messages are the carries of information. Usually, the bus does not preserve the message order as this additional logic is not required. The main motto of the Message Bus can be described in such a way: logically centralized, physically decentralized [11]. The bus, which is the main building brick of the integrated application, supports distribution in a federated manner, which means that constituent buses cooperatively implement the greater system with the same functions as the constituent buses. This is the exact example of the federation pattern described in Section 2.3.2. Distribution and federation are the key aspects provided by the bus. The messaging mechanism of the bus can be implemented using one of these: • Message router; • Publish/subscribe mechanism; Message Router The main goal of message router is to consume messages from one channel and republish them to different target channels depending on a set of conditions. What is also important, message router does not change the content of the routed messages. The taxonomy of message routers is presented from the ”Enterprise Integration Book” [88]. • Content-Based Router - examines the message and makes routing decision based on the content of the message;


18

• Message Filter - has only one output channel; when message matches specified criteria, it is routed, when not it is dropped; • Recipient List - computes recipient list, then sends copy of message to all recipients; • Splitter - publishes new message for each element of the original message • Aggregator - gathers and correlates messages, then sends correlated messages as a one message to the output channel; • Resequencer - contains an internal buffer; it stores out-of-sequence messages until a complete sequence is obtained, then the messages are routed; • Composed Message Processor - splits the message up, routes the sub-messages to the appropriate destinations and re-aggregates the responses back into a single message; • Scater-Gather - routes a request message to the a number of recipients; collect the responses and distill them into a single response message; • Routing Slip - attaches the routing list to the message and sends the message to the first recipient from the list; the recipient sends the message to the next recipient from the list; the process is repeated until the end of the list is reached; • Process Manager - uses a process manager to generate processing sequence and to determine next step on the basis of intermediate results; Publish/Subscribe Mechanism The main goal of publish/subscribe mechanism is to send a message, whenever it is published, to all subscribed recipients. There are three main types of Publish/Subscribe pattern [16]: • List-Based Publish/Subscribe - keeps a list of published topics and subscribers and notifies each one on event; • Broadcast-Based Publish/Subscribe - does not determine the subscribers; broadcasts the message to all recipients in the bus; • Content-Based Publish/Subscribe - matches message against specified criteria and then sends message to interested subscribers; Summary Currently, message Bus pattern goes one step further and takes the lead. Not only does it contain all advantages of the broker architecture, but it also solves some inconvenient problems. It simplifies and standardizes the approach of integration as well as introduces a federated manner of solving the broker clustering problem. Message buses are one of the most sophisticated integration solutions and are nowadays widely used in business.


2.3.7

19

Comparison

Figure 2.8 summarizes the main integration topologies showing their hierarchy. All of these topologies were described in the chapter above.

Figure 2.8: Topology Summary8

At the end a short comparison of the Message Broker and Message Bus will be presented as these two patterns are frequently confused. 8 Figure


2.4. Enterprise Service Bus

20

Table 2.1: Topologies comparison

Topologies comparison Message Broker Message Bus Implements the pattern of mediation; Implements the pattern of federation; Physically centralized broker; Logically centralized, physically decentralized bus; Distribution of integration logic only by clus- Distribution of integration logic by federation tering the central machine on which the bro- of buses, local clustering of each bus is also ker resides; available; Broker is a monolithic software; All integra- Different components cooperate to provide tion services are embedded into the hub; integration services; Pluggable architecture provides reusability; Usually, broker can be used in ”all or noth- Selective usage model of bus functions is posing” mode”; sible; Exposes many different, proprietary inter- Based on one common description language faces, each for a distinctive application type which attempts to reconciliate data model or data model; and application specific approaches; Usually a proprietary solution; Standardized solutions exist;

2.4

Enterprise Service Bus

It has to be admitted that there is no agreed-upon definition of what an Enterprise Service Bus (ESB) actually is. The term was initially invented by Sonic Software to refer to their solution named SonicXQ later renamed to SonicESB. There is much ambiguity, confusion and buzz around ESBs caused by companies which seem to offer ESB like solutions. To prove that concept, some quotations presenting contrasting ESB definitions will be presented [79]: • ”A Web-services-capable infrastructure that supports intelligently directed communication and mediated relationships among loosely coupled and decoupled biz components.” Gartner Group; • ”The ESB label simply implies that a product is some type of integration middleware product that supports both MOM and Web services protocols.” Burton Group; • ”A standards-based integration backbone, combining messaging, Web services, transformation, and intelligent routing.” Sonic Software; • ”An enterprise platform that implements standardized interfaces for communication, connectivity, transformation, and security.” Fiorano Software; • ”To put it bluntly: If you have WebSphere MQ and other WebSphere brokers and integration servers, you have an ESB.” Bob Sutor, IBM; • ”The Enterprise Service Bus is a uniform service integration architecture of infrastructure services that provides consistent support to business services across a defined ecosystem. The ESB is implemented as a service oriented architecture using Web Service interfaces.” CBDI;


21

Smoke screen created by this definitions completely covers the main goal and general purpose of the ESB. Straightforward architectural definition of this pattern will be presented later on, but firstly the environment in which the ESB resides, will be briefly introduced as these two elements are tightly connected.

2.4.1

Service Oriented Architecture as ESB environment.

Service Oriented Architecture is a technology-independent software architecture which specifies a certain set of rules how to build and maintain distributed applications. It presents an approach to designing computer systems which consist of autonomous services. The discussion on what a service actually is, looks somehow similar to the discussion about the definition of an object in early nineties. OASIS defines service as [68]: ”a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” Simplier, the service represents an autonomous business logic or technical functionality defined by an agreed-upon service description. Figure 2.9 presents the overview of SOA.

Figure 2.9: Location of ESB in SOA environment9

In the SOA environment services consist of: • contract - specifies the pre and post conditions, functional and non-functional requirements as well as the type of the service; • implementation - the core business logic which operates on the provided data and returns the result; • interface - short description of the service; 9 Figure



22

The main guiding principles of SOA accroding to [70] are: loose coupling, reuse, granularity, modularity, composability, componentization, and interoperability. Not going into details, it means that services are reusable and granular building bricks or the low level entities which application should consist of. Whenever a system is built, a developer chooses required services, designs the business process and composes the applications using, for example, a graphical tool. Great emphasis is put on the reusability as it was a main concern of the software industry. What is very important, SOA is technology independent. It is a common mistake to claim that SOA is tightly coupled with the Web Services. SOA architecture can be implemented using a wide variety of technologies, like [70]: SOAP, REST, RPC, DCOM, CORBA, WCF or last but not least Web-Services. Summing up, SOA is a modern, thoroughly different approach to software design from the previous ones, as earlier computer systems were formed as monolithic, coarse-grained, unreusable entities. The primary goal of SOA is [56] ”to align the business world with the IT world in a way that makes both more effective”.

2.4.2

ESB Definition

SOA architecture defines the set of rules how to design and implement a distributed application. These rules apply whenever new applications are created, as well as when old or legacy systems are redesigned. ESB pattern greatly fits into the SOA since it is fully compliant with its paradigms. It encompasses all amenities of SOA as well as provides a set of sophisticated features, described later on. Definition of an ESB presented in this work goes as follows: ESB is a pattern which is the SOAoriented extension of the bus integration pattern. It is an integration pattern as it fulfills all the required conditions which are described in Chapter 2.3.6. However, ESB goes beyond as it is SOA oriented. It is not supposed to implement SOA architecture but it was invented to facilitate the engineering and utilization of modern SOA. Alike SOA, ESB is not bound to any specific technology, it only defines a set of features which a ESB solution should consist of. Generally, on the highest level of abstraction ESB provides: • Bus integration pattern; • SOA runtime environment; ESB as integration pattern In the area of SOA, integration can be described as service virtualization [57], what describes the feature of virtualizing the following factors during the service interactions: • Protocol and pattern - the participants of interaction need not use the same transfer protocol (TCP, UDP, HTTP, SOA, etc.) or interaction pattern (synchronous/asynchronous, requestresponse, only-in, etc.). ESB should provide the whole required mediation. • Interface - requester and responder need not use the same interface of the same service. ESB should provide the ability to separate Business Service (contract 2.4.1) from Service Implementation (implementation 2.4.1) and interface;


23

• Identity (transparency of the service location) - the requester of interaction need not know the identity (for example address) of the responder to request a service. Service could be provided by any of providers from different physical locations. The list of providers and their identities is known only to the ESB and, what is important, may change without impacting the requester side. ESB as a runtime environment One of the most important principles of ESB as the runtime environment is the aspect oriented connectivity [57] which allows to inject cross-cutting aspects between service invocations in order to add the support of: security, management, logging, auditing and transaction management. This feature is similar to the Request Interceptor specified in the Enterprise Service Beans standard. ESB should also embed the advantages of an application container and provide the services with the runtime facilities such as the support of deployment in a high availability configuration. The environment should also support scalability, management and reliability. ESB capabilities According to Mark Wright, [108] ESB should be defined by specifying the core facilities which form the main characteristics of an ESB. They can be grouped under the parent, logical component which they belong to. However, in this work the definitions as well as the grouping are extended, redefined and brought to the different level of abstraction. The list of ESB logical components and their functions is presented below. Rules Engine (can be implemented by the Message Router, described in detail here: 2.3.6) • Routing; • Message Transformation; • Message Enhancement; • Message Processing; Service Registry: • Service Mapping - ability to map service contract into the corresponding service implementation; Service Mediator: • Protocol Transformation - ability to expose service using different types of protocols; possible thanks to the usage of CDL; Business Processor (ability to coordinate complex business processes): • Service Orchestration - orchestrates service in order to form a business process; services are coordinated in a centralized way, coordination requires a central point - mediator; processes can be specified using, for example, BPEL;


24

• Service Choreography - coordination realized in a decentralized manner; can be implemented using the ”routing slip” function of the message router; Service Container: • Security (Authentication and Authorization); • Transaction Support; • Context Propagation; • Management; • Logging; • Deployment environment; Service Manager (Monitoring features will be discussed later on): • Business Monitoring - ability to track, monitor, analyze and profile logical business operations, executed in the bus; • System Monitoring - ability to monitor main system characteristics and quality informations; • Service Level Agreement - business auditing; Federation of ESBs Federation (2.3.2) is one of the main concepts which the message bus pattern is based on. However, in reference with Enterprise Service Bus, this paradigm was specified mainly theoretically; some of the implementations do not support it at all. Currently, some trends of change are emphatically visible since the newest Forrester report [85], dated April 2008, reads as follows: ”The enterprise service bus (ESB) is not a single entity across the enterprise but a federation of ESBs and other SOA infrastructure that work together to ease and control service usage across the enterprise.” According to this report: ”ESB federation enables multiple ESBs to work together, seamlessly and transparently, to enable enterprisewide access to and management of services across multiple domains, each of which has potentially different requirements for security, visibility, mediation, quality-of-service, and management.” This definition, completly compliant with the federation pattern described earlier, seems to head of the right direction as the main drawback of the up-to-date ESB solutions is noticed and there are attempts to resolve it. According to the report, three models of federation are possible: • Direct federation - ESBs which host services are directly connected; • Brokered federation - many ESBs, one acts as a mediator and hosts no services; all the other ESBs host services and connect with each other using the mediator; • Full federation - many ESBs, one acts as a mediator but also can host services; direct or indirect communication possible;


2.4.3

25

ESB implementations

There are many software solutions which are claimed to be ESB compliant, however some of them have the ESB only in theirs name. The list presented below outlines the main ESB implementations presenting the name of the product as well as the producer. • Aqua Logic Service Bus, BEA; • WebSphere ESB, IBM; • JBoss ESB, JBoss; • OpenESB, SUN Microsystems; • ServiceMix, Apache; • Enterprise ServiceMix (FUSE), Iona; • SonicESB, Sonic Software; • ESB, IWay Software; • WSO2 Enterprise Service Bus, open project; • ChainBuilder ESB, Bostech; • Mule, open project; • PEtALS, OW2; • BizTalk Server products family, Microsoft;

2.4.4

Summary

ESB is currently one of the most up-to-date solutions in the area of enterprise integration and service oriented architecture. It is considered to have significant influence on design of distributed software solutions across the world. It proved to be very successful and now it is a top-selling product offered by most of the major IT market players. However, in a meaningful article [56] Bobby Woolf, respectable software architect and co-author of the ”Enterprise Integration Patterns” book, questions the legitimacy of an ESB. The author claims that it is not beneficial to adopt an ESB without an attempt to identify, design and implement the autonomous services, which are the underlying, building bricks of every SOA. It is stated that clients want to build only ESBs not paying attention to business requirements, as they seek rapid profit growth. They want to create an infrastructure and then wait and hope that some SOA will use it. Author puts the emphasis on the fact that ESB without services does not create a business value as this is a useless infrastructure without customers (services) which benefit from it. The main motto reads as follows: ”Don’t build an ESB by itself; build it as part of a SOA”.


2.5

26

Java Business Integration

In contrast to the ESB, definition of the JBI is clearly specified in JSR 208. Althought the word ESB can be found only once in the whole document, these two terms have a lot in common. According to the specification, [2] ”Java Business Integration (JBI) seeks to address EAI problem by creating a standards-based architecture for integration solutions. This infrastructure allows thirdparty components to be ”plugged in” to a standard infrastructure, and allows those components to interoperate in a predictable, reliable fashion despite being produced by separate vendors. It is anticipated that this ability to interoperate will create a multivendor ”ecosystem” which will give rise to large pool of integration-related technologies that can be sourced by end users. In addition, this ecosystem will foster new innovations in integration technologies since it will permit innovators to concentrate on a particular technology or problem area, without having to worry about providing all the other pieces needed to build a complete integration solution. (...) JBI defines what is sometimes termed a ”service container” in Enterprise Service Bus (ESB) systems”. To sum up, JBI standardizes the ESB pattern by specifying a concrete, Java-centric model of ESB.

2.5.1

Background

Looking back, JBI is the ”last but not least” integration technology presented in this work. All the previous definitions were introduced to present the taxonomy of enterprise integration patterns, describe the most popular solutions and preciously outline the background and origin of JBI. At the current stage, when it is stated that JBI derives from ESB which derives from bus integration, all underlying concepts should be well-known. JBI fulfills all conditions to be characterized as enterprise service bus (2.4.2). The list below accurately explains and summarizes all the JBI features with the reference to ESB. • JBI is an integration pattern (2.4.2) as it virtualizes: – communication protocol; – communication pattern; – interface and identity; • JBI is a runtime environment (2.4.2). It is often called a ”container of containers”: – container for plug-in components; – container for service artifacts which resides in plug-in components; • JBI acts as intermediary. Components do not interact with each other directly, they communicate by means of mediated message exchange governed by the normalized message router (NMR) instead (2.3.6). • JBI is SOA-oriented as it embraces a service-oriented approach. It is based on Web Services model. • JBI encompasses all the capabilities each ESB should consist of (2.4.2). • JBI is standardized and based on open standards:


27

– JBI is dependent on either J2SE 1.4 or J2EE 1.4; – JBI uses WSDL(1.1 and 2.0) as the common description language (CDL); – Interacion makes use of XML based messages (XML 1.0); – Processing uses the JAX-RPC 2.0 model; – JBI makes use of Java Management eXtenstion (JMX); – JBI defines ”service container” defined by ESB pattern;

2.5.2

Architecture

Figure 2.10: Architecture of JBI10

JBI consists of many elements which operate together to form runtime environment for the utilization of SOA. The solution is complex (Figure 2.10), thus its description is grouped by the logical component or function. It is impossible to briefly describe all the features JBI contains, prior JBI knowledge is required. Therefore, some general ideas of high-level architecture will be presented. Unified Service Description JBI specifies a declarative model of services using Web Services Description Language (WSDL versions 1.1 and 2.0). Agreed-upon and unified service description is crucial as every party understands it - mediation among service invocations is not required. Message-based services are declared on two levels (Figure 2.11): abstract and concrete. This kind of design derives from 10 Figure



28

Figure 2.11: JBI Messaging Model10

object-oriented design, where interface and implementation are decoupled. Specification of abstract and concrete service model keeps the configuration tidy and avoids redundant pieces of information. Abstract service model describes a service in a general way. It describes messages which are sent during invocations of operations and groups these operations into interfaces. Concrete model specifies services as the implementation of the abstract interfaces. A service consist of endpoints which offer access to the service implementation through different bindings protocols. Aforementioned mechanisms present the ability of JBI to separate the business service (contract) from service implementation and interface, which is explained in detail in Section 2.4.1. Normalized Message A concept of message normalization is used in JBI. It is the carrier of data between consumers and providers. It encompasses invocation arguments as well as operation results. Normalized message consists of three main parts: • Message Content (payload) - normalized XML document, conforming to specified message scheme; content carrier; • Message Properties - metadata of the message; holds additional data added to the message during the processing of the message; metadata can be added by plug-in components as


29

well as system components; • Message Attachment - additional part of the content, which is ,for example, non-XML, can be attached as an attachment; data handler for such content has to be specified; The main goal of the normalized message is to provide interoperability between components. Normalized Message Exchange Message exchange is the logical entity which describes communication between consumer and provider in JBI. Not only does it serve as the container for normalized messages that take part in the exchange, but it also represents the JBI-local portion of service invocation. Message exchange introduces the communication pattern which specifies steps of communication. There are four communication patterns: • In-Only - standard one-way messaging pattern; consumer initiates with a message; provider replies only with status response that indicates that the exchange is over; • Robust In-Only - reliable one-way messaging pattern; consumer initiates with a message; provider replies with status or fault response which indicates the correctness of the exchange; • In-Out - standard two-way messaging pattern; consumer initiates with a message; provider replies with status or fault response which indicates the correctness of the exchange; consumer responds with a status; • In Optional-Out - standard two-way messaging pattern; provider response is optional; Normalized Message Router Delivery of the messages which take part in message exchanges is provided by the normalized message router (NMR) which is the core of JBI. It performs operations with different qualities of service depending on multiple factors, like application state or nature of the message. Three qualities of service are supported by the NMR: • Best effort - no guarantee of message delivery; message can be dropped, delivered once or more than once; • At least once - message will be delivered once or more than once; • Once and only once - message will be delivered exactly once; Components JBI introduces two types of components which can realize two different roles: consumer and provider. Components are installed during the process called ”Component Installation”. • Binding Component (BC) - BC provides the virtualization of communication protocol and pattern by performing normalization and denormalization from and to the protocol-specific


30

format. It provides the NMR with the possibility to deal only with normalized communication format. Each BC ”understands” one communication protocol and behaves like connector which allow different kinds of communications with the bus. BC can perform operations playing two roles (separately or simultaneously) : – consumer role - it enables the services deployed in the bus to communicate with external services. – provider role - it enables external customers to communicate with the services deployed in the bus. • Service Engine (SE) - SE provides business logic services and transformation services in the JBI environment as well as consume such services. SE enables to construct low-grained complex processes by aggregating and orchestrating other services as well as creates simpler, fine-grained services, for example data transformation and enhancement. SEs act as containers as they form the runtime environment for services. Whenever a new service is created it is deployed to specified SE which supports the technology using which the service was implemented. SE can serve as service provider, consumer or both. Component Framework JBI provides the component framework which enables the components (BCs and SEs) to interact with the JBI environment. All the interfaces are agreed-upon and specified. There are two types of interfaces: • API (application program interface) - exposed by the JBI framework to BCs and SEs; defines the contract between JBI environment and pluggable components in order to achieve functional goals; • SPI (service provider interface) - interfaces implemented by the components; Artifacts JBI components behave as a type of container which new artifacts are deployed to in order to add new service consumer or provider logic. For example, it is possible to deploy new style sheets to XSLT-transformation service engine to provide it with new transformation logic. The process of adding such component-specific artifacts is called ”Artifact Deployment”. There are two types of artifacts: • Service Unit (SU) - single deployment package, destined for a single component; content of service units is not specified as SUs are opaque to JBI; each SU must contain a JBI-defined descriptor file in which static services (endpoints) produced and consumed by this SU are defined; • Service Assembly (SA) - equivalent of consumer application; SU artifacts are grouped under a higher level entity, called service assembly (SA), which is a set of SUs. Each SA contains service deployment descriptor which specifies to which component each SU is to be deployed. SA concept is sometimes called ”composite service description” (CSD);


31

CSD plays a significant role as it provides the JBI environment with the information about service connections between SUs and providers. These data are grouped under two categories: • ”Description of static services provided and consumed as a result of deployment of a service unit” [2]. • ”Description of static service interconnections between the services units of the service assembly, as well as dependencies on services offered outside of the service assembly (i.e, services provided elsewhere in the JBI environment” [2]. Management JBI bus is fully administrable through the JMX. Specification outlines several JMX beans in order to provide full control over the JBI environment. Most significant functions of the management beans are the life cycle management of the components, installation of engines and bindings as well as deployment of component artifacts to executive environment. Message Exchange Flow One of the most important JBI environment’s functions is to route message exchanges during the interaction between service consumer and service provider. It illustrates all features that are ”under the hood” of JBI. Figure 2.12 depicts the standard In-Out Message Exchange.

Figure 2.12: Message Exchange Flow11

The interaction consist of many phases. 11 Figure



32

1. An external service consumer sends a service request to a binding component (acting as a consumer component in this case) using particular transport protocol. The consumer component normalizes the service request using specified format described in WSDL model. BC creates message exchange, creates ”in” message with the normalized service request and sends it to JBI Environment. 2. The JBI environment selects service provider and routes message directly to it. The provider pulls the message exchange using accept method and obtains invocation parameters from the ”in” message. 3. The Provider component invokes business logic requested by the consumer. The results of the invocation are stored in the normalized form in the ”out” message of the message exchange. 4. Message exchange with the ”out” message is sent to the JBI environment. 5. JBI environment recognizes the message exchange and routes it directly to the consumer which pulls it using accept method. 6. The result of the requested service is denormalized and returned to the consumer using the particular protocol and transport, which the consumer previously used. 7. The consumer component sends status to the provider component. 8. The providing component pulls the status message from NMR using accept method. 9. Message exchange terminates. Federation The main drawback of JBI is that it specifies neither distribution nor federation. This fact significantly diminishes the wide variety of the ESB usage scenarios, which JBI implements, causing that this technology places itself between hub and spoke and ESB pattern.

2.5.3

JBI Implementations

The following table presents the state of the art of JBI implementations at two different points in time: the beginning of the research concerning this thesis and the current moment. Table 2.2: JBI implementations

Q1 2007 JBI based JBI certified ServiceMix OpenESB Mule

Q3 2008 JBI based JBI certified ServiceMix OpenESB Mule OW2 PEtALS JBossESB ChainBuilder Fuse ESB

2.6. Conclusion

33

At the beginning, it was decided that OpenESB and SericeMix would be evaluated as these were the only two solutions that were worth mentioning with reference to JBI compliance. OpenESB was certified to be fully JBI compliant, while ServiceMix was considered to be ”almost” JBI compliant. ServiceMix developers claimed that only some slight incompatibilities exist. In the first quarter of 2008, it turned out that PEtALS is also an absorbing solution which is probably ahead of ServiceMix. However, it was too late to include it in the subject of the performed research.

2.5.4

Summary

The future of JBI is currently unknown. The approach to standardizing enterprise service buses seems to head off the right direction. The first version of the specification was approved by most of the major ESB vendors, which set great stores on the tight standardization of ESB. However, later on the general assumptions of the JSR group were partially fulfilled as not many steps were taken by major ESB vendors to unify existing implementations in compliance with JBI. Only two JBI certified solutions were designed from scratch after the publication of the JSR, which indicates that there were not many movements in the ESB community. It is also very hard to evaluate the market share of these solutions which does not seem to be meaningful. The uncertain future of JBI is confirmed by the revision summary of the second version of specification which was rejected by the two main ESB providers that remain unconvinced of the value of JBI solution for SOA. At the current moment, it is hard to predict the significance of JBI. According to many resources, the future of ESB is beyond any doubt, only time can clarify the role played by JBI.

2.6

Conclusion

The presented chapter outlined a thorough examination of the Enterprise Application Integration. Theoretical research was very important at this stage of work as it broadened the view of the core concepts which are discussed across this paper. Precise definition introduced in this chapter helped to demystify the real differences between integration patterns and laid a grate foundation of clear and accurate theoretical background. It occurred that point-to-point integration is the most intuitive solution. However, its applicability is very limited. It is beneficial only for small systems consisting of restricted number of elements. If that border is outrun, problems rapidly accumulate. Broker integration seemed to eliminate main problems met in the previous pattern. It is scalable and expansible. The main problem concerning broker integration is that its implementations are usually proprietary and based on closed standards. It results in an expensive and unmanageable solution which is hard to maintain. Broker is also a single point of failure, which is unacceptable in some cases. Bus integration pattern is supposed to solve all problems which are mentioned above. Logically centralized, physically decentralized integration topology which is based on commonly known standards and technologies. Shortcomings are almost imperceptible. ESB tends to develop this trend helping to facilitate the utilization of SOA. At the end Java Business Integration (JBI) is introduced. It is defined as a standardized, java-oriented implementation of ESB. All its architectural characteristics are described in order to provide a close examination of the specification. Most of this information is required by following chapters whose main goal is to investigate JBI in order to propose its generic monitoring architecture. Chapter is finished with discussion

2.6. Conclusion

34

concerning the future of JBI. It is very hard to predict, whether the specification will be successful since many signs precede the gradual deterioration of its significance. All of the facts mentioned earlier formed a complete description of the target technologies. They have also deepened the knowledge in the specific domain of the thesis.

Chapter 3

JBI Monitoring It is not enough to have great qualities; We should also have the management of them. Francois de la Rochefoucauld, a French classical author, leading exponent of the Maxime.

3.1

Preamble

The previous chapter introduced the main concepts: Enterprise Application Integration, Enterprise Service Bus and Java Business Integration, which are the subject of the monitoring system presented in this thesis. This deep analysis of ESB and JBI essentials gives an appropriate background for discussing the aspect of monitoring enterprise applications, which is the content of this chapter. The content is structured in a top-down manner. At the beginning, an enterprise monitoring abstraction is provided which is extended in the following sections relating to JBI specification and some already defined monitoring theories. Finally, the incremental approach is summarized by identification of JBI monitoring as a non-trivial challenge. The monitoring characteristics introduced in the monitoring abstraction are referred to throughout the rest of the chapter and allow to evaluate the monitoring capabilities defined in JBI as well as those provided by OpenESB and ServiceMix implementations. The evaluation is performed in JBI status quo section, which additionally discusses the important feature of clustering. It is discussed in the context of ESB federation introduced in the previous chapter. Clustering support increases difficulty of JBI monitoring systems and implies the need of a theoretical background provided by Application Response Measurement and Business Application Monitoring. The last section discusses the influence of all aspects mentioned in this chapter and tries to grasp the architecture implications. It has to be stressed that the entire content of this chapter is intentionally kept at an abstraction level, which does not refer directly to GlassBus solution that has been introduced later. Focusing on enterprise monitoring aspects without solution, the context gives a better justification for decisions made in further chapters.

3.2

Monitoring abstraction

This section tries to identify some general well-known monitoring abstraction and, having failed to do so, it proposes a simple substitute in the form of a monitoring system classification. According to a research performed for the purpose of this thesis, a general monitoring theory applying to Enterprise Service Bus environment does not exist. There are specifications aiming to standardize application server monitoring, e.g. JSR-77: J2EE Management [17], but such an approach does not comply with ESB. A theoretical background would allow for a later contextual

3.2. Monitoring abstraction

36

definition of our solution’s capabilities. The shortcomings and advantages of the system would be clearly visible in the context of a more general monitoring abstraction. The lack of a monitoring abstraction was the motivation of the subject analysis, which resulted in putting forward a monitoring system classification. Monitoring systems can be classified on the basis of their various characteristics. After evaluation of the key characteristics related to monitoring, the following system division has been created: 1. Mechanism of information acquiring — How does a system measure the resources that are the subject of monitoring? • log analysis — the information regarding the resources is extracted from the logs produced by the resources. It requires constant log parsing and identifying the data that is important from the monitoring point of view. • code instrumentation — the resources are equipped with new functionalities that allow to intercept monitoring events as soon as they appear and on this basis to update the monitoring parameters. 2. Model of monitoring parameters evaluation — What patterns are used for the querying of resources? • constant pulling — the resources are constantly being queried. When the response changes, the monitoring engine updates the parameters. The information is pulled from the resources to the system. • event-driven tracing — the resources trigger events at the status change that are received by the system and processed to some monitoring parameters update. The information is pushed by the resources to the system. 3. Mechanism of information exposition — How can the external system access the system’s monitoring parameters? • log file — change of the monitoring parameters or periodical status is reported to a log file. • well-defined interface — each monitoring parameter is exposed through an interface which defines syntactical and semantic details. 4. Model of monitoring parameters exposition — What patterns are used for the exchange of the data with external systems? • request-response interface — data exchange is realized with a plain old request-response in a synchronous way (information is pulled by an external actor). Method signatures (or some generic data format) is known a priori. • notification oriented interface — the data is pushed to an external actor by means of notifications. Generic data format is known a prori. 5. Monitoring subject — When analyzing a computer machine (regardless of whether it is one computer or a whole cluster), the monitoring parameters can obviously be divided to system specific and application specific. A list of sample parameters specific to each monitoring type can easily be provided:

3.3. JBI monitoring status quo

37

• application — free RAM memory, free hard disk space, CPU usage, number of system processes, number of running applications, each application RAM and CPU usage, network bandwidth usage [107]; • system — number of related network connections, response time from the user’s point of view, persistence level errors, business level errors, modules usage statistics, business operation performance; Depending on the particular monitoring system’s scope and subject, the division into application and system can be related to different aspects. 6. Time context — How is the available monitoring information related to the present state? • historical information — there is a record of monitoring parameters history. Queries about both the past and present status can be made. • current information — only the present status is maintained. Past information is overwritten with newer information. 7. Monitoring update delay — How far from the present time is the newest available monitoring state positioned? • monitoring of real-time — there is no delay between the event and monitoring parameter update. • monitoring of relative near past — there is significant delay between the event and update. The proposed classification takes the meaningful characteristics of a monitoring system into account, but does not perform any detailed analysis. Its purpose is to provide some reference point to a wide range of specifications, technologies, patterns and implementations that are within the scope of this thesis.

3.3

JBI monitoring status quo

In order to propose a solution for a monitoring JBI container, a state-of-the-art analysis has to be performed. As it has been defined in the introduction (1), the objective of the thesis is to propose a system complying with JSR-208 and successfully operating on the open source JBI implementations: ServiceMix and OpenESB. This section goes through JBI, ServiceMix and OpenESB analysis and it extracts information relevant to monitoring, ipso facto creating the environment for establishing the JBI monitoring solution.

3.3.1

Monitoring from JSR

Java Business Integration introduces basic management and monitoring mechanisms based on the Java Management Extensions (JMX) technology. Thanks to the design of the JMX architecture, API, patterns and appropriate services supporting both networks and applications, it allows to control and query various resources: network elements, system compounds, application objects, enterprise components. JMX architecture’s flexibility is achieved by a division into the following layers: • Instrumentation level;


38

• Agent level; • Distributed services level; The resources managed with JMX are instrumented with Managed Beans (MBeans) and are the primary architecture entities residing on the instrumentation level. Further JMX details are not described in this thesis — authors assume that JSR-003 and JSR-160 [18, 19] are known to the reader. JBI specification uses MBeans from the instrumentation level to define the management skeleton interface, which provides the following functionalities: • Installation of engines and bindings (components); • Life cycle management of components (start/stop controls); • Deployment of component artifacts to engines and bindings; • Monitoring and control; Unfortunately, most of the methods of JBI’s MBean interfaces are used for management and there are only a few that can provide functionality of monitoring. The following methods have been identified as valuable for monitoring (description of the methods has been omitted due to their self-explanatory names): • AdminServiceMBean.getBindingComponents(); • AdminServiceMBean.getEngineComponents(); • DeploymentServiceMBean.getDeployedServiceUnitList(componentName); • DeploymentServiceMBean.getDeployedServiceAssemblies(); • DeploymentServiceMBean.getServiceAssemblyDescriptor(saName); • DeploymentServiceMBean.getDeployedServiceAssembliesForComponent(component); • LifeCycleMBean.getCurrentState(); • InstallerMBean.isInstalled(); These methods can provide the basic information about the structure of the bus: what BC, SE, SU and SA are installed/deployed and which of them are currently running. Such information is valuable, however there are other important statistics that have to be exposed in a complete monitoring solution. The conclusion is that JSR-208 does not define a sufficient monitoring infrastructure. The specification basis has to be enriched in order to comply with the assumptions from the theoretical discourse included in the previous chapter (3.5.2).


3.3.2

39

ServiceMix monitoring

The monitoring capabilities of ServiceMix exposed by JMX do not really go beyond those defined in JBI. In ServiceMix versions used for the purpose of this thesis, i.e. 3.1.2 and 3.2.1, only the following monitoring parameters were available 1 : • getInboundExchangeCount; • getInboundExchangeRate; • getOutboundExchangeCount; • getOutboundExchangeRate; These parameters can be obtained in the context of a particular endpoint or component giving the information about MessageExchanges counts and rates. ServiceMix extension to JSR MBeans does not introduce any significant functionalities. However, the Bus is equipped with other interesting mechanisms meaningful for monitoring. CorrelationId The first of ServiceMix’s monitoring mechanisms is CorrelationId. In order to avoid confusion it has to be stressed that it is used in two meanings: as the name of the mechanism which processes correlates - MessageExchanges that flow through the Bus and as the name of MessageExchange’s property, which preserves the actual id of a particular correlation. Each JBI MessageExchange is uniquely identified through its own id. ME can appear in the bus as a reaction to some external event (e.g. invocation of some web service exposed by a http binding component) or as a reaction to processing some other MessageExchange (internal event). MessageExchanges created while processing internal events can be correlated with a parent MessageExchange. The process of correlation can be performed recursively up to the point when MessageExchange has been created for an external event response. It allows to correlate each MessageExchange with a root MessageExchange triggered by an external event. ServiceMix’s CorrelationId mechanism uses the above-mentioned correlation process and marks each MessageExchange with a property of CorrelationId. The value of CorrelationId property is the id of the related root MessageExchange. The mechanism of correlating MessageExchange into what is known as the JBI transaction is presented in great detail in Section 4.3. Please refer to it for a complete understanding. Event interception ServiceMix introduces a very flexible mechanism for intercepting various events occurring in the bus. The mechanism relies on a definition of event listeners provided in the package org.apache.servicemix.jbi.event. The implementation of each listener is notified about specific events. The following listeners interfaces are available: 2 : 1 Information about parameters available in earlier versions of ServiceMix is available here: http://servicemix.apache.org/management.html 2 http://servicemix.apache.org/maven/servicemix-core/apidocs/org/apache/servicemix/jbi/event/packagesummary.html


40

• ComponentListener — notifies about component installation, deinstallation, starting, stopping, shutting down. • DeploymentListener — notifies about file modifications (ServiceMix specific). • EndpointListener — notifies about endpoint registration and unregistration. • ExchangeListener — notifies about sent and accepted MessageExchanges. • ServiceAssemblyListener — notifies about ServiceAssembly deployment, undeployment, starting, stopping, shutting down. • ServiceUnitListener — notifies about ServiceUnit deployment, undeployment, starting, stopping, shutting down. In order to be able to use the described mechanism, an implementation of one of the above interfaces has to be provided and registered in ServiceMix using the following method: JbiContainer.addListener(EventListener listener). Unfortunately, such an event interception is not compliant with JBI specification. Additionally, there is no similar mechanism in OpenESB — listeners are specific to ServiceMix. There are few useful components which use the mechanism of event listeners. They are presented in the following paragraphs. Component and Endpoint visualization ServiceMix has a built-in functionality of bus topology visualization. Notifications of ComponentListener, DeploymentListener and EndpointListener allow to track changes in the topology. Thanks to that, maintaining of the installed, started components and the endpoints deployed to them is possible. The knowledge about topology is a good basis for further analysis of MessageExchange flows occurring between the endpoints in the topology. The topology is provided in a file with the components and endpoints graph described in the DOT language [20]. DOT is a simple plain-text description language which is understandable to both humans and computers. DOT files created by ServiceMix have to be further visualized by one of the many tools capable of DOT handling 3 . This step is performed outside of ServiceMix by the users themselves. MessageExchange flow visualization Another ServiceMix’s visualization tool which is complementary with the topology provides information about MessageExchange flows. Implementation of ExchangeListener is used, which allows to intercept events of sending and accepting MessageExchanges in DeliveryChannels of all components running in the bus. MessageExchange interception is enhanced with CorrelationId feature allowing for creating trees of message exchange flows. As in the case of the topology description, the flow is also provided in DOT language files and the final step of visualization is the user’s responsibility. Tracing the paths of MessageExchanges is a meaningful capability that may be used for debugging business logic deployed to the bus. 3 Graphviz - http://www.graphviz.org/ ; AT&T Grappa - http://www.research.att.com/ john/Grappa/ ; C++ BGL http://www.boost.org/doc/libs/1 35 0/libs/graph/doc/index.html


41

ServiceMix Audit Audit is one of the ServiceMix’s modules. It focuses on MessageExchanges, which to some extent is analogical to the flow visualization. However, Audit is not concerned with correlation, maintaining instead a historical record of MessageExchanges. Recorded MessageExchanges are also intercepted in ExchangeListener (see: flow visualization). The module provides an abstraction of the persistence layer allowing for flexible change of the persistence realization. At the moment, two realizations are available: • FileAuditor — storing exchanges in regular files; • JdbcAuditor — storing exchanges in any JDBC compatible resources. For the purpose of performance only one table with a message id and serialized content is used; The persistence layer is additionally enhanced with a full-text search engine - Lucene 4 . It appropriately indexes recorded message exchanges allowing for further content-based search. Just as in the case of the flow visualization, it can be used for debugging, but also as a means of statistics and some business oriented analysis (cf. Business Intelligence 3.4.2). Spagic Spagic describes itself as a SOA Enterprise Integration Platform. On the homepage, the following description is provided: ”Spagic is a solution composed by a set of visual tools and back-end applications oriented towards design, realisation, deploy and monitoring of ESB infrastructures adherent to the SOA paradigm.” The solution’s monitoring aspect is interesting for the purpose of this thesis, but the remaining details are out of its scope [21]. Spagic monitoring refers to an abstraction of a higher level process (analogical to business process) which is realized by means of ESB, BPM and also JBI. Spagic uses ServiceMix for the purpose of Java Business Integration. The higher level process part, realised by JBI (ServiceMix), can be actively monitored. It comes to following the business transaction through its endpoints and reporting success or possible failures. Monitoring uses two ServiceMix’s mechanisms: • ExchangeListener — used to intercept MessageExchanges; • CorrelationID — for business transaction constructing; Spagic’s broad functionalities and its monitoring aspect prove the usefulness of the monitoring mechanisms of ServiceMix.

3.3.3

OpenESB monitoring

OpenESB monitoring realization approach differs from the ServiceMix approach. OpenESB lacks valuable mechanism introduced by ServiceMix: CorrelationId and Event Listeners, but it provides a well-designed Sierra framework dedicated to runtime monitoring. The framework is described on OpenESB Wiki pages [22], which, along with our experience and the results of experiments, provides the main reference for this section. Sierra monitoring focuses mainly on performance characteristics which span across system and application monitoring types defined in Section 3.2. This means that every JBI role will benefit from the monitoring parameters provided by Sierra (cf. 3.2). The performance evaluation is applied very systematically. Firstly, the framework finds the primary JBI entities, in which the context 4 Apache

Lucene - http://lucene.apache.org/java/docs/


42

performance can be evaluated: Normalised Message Router, Delivery Channel, Endpoint (their detailed description can be found in JSR-208 [2]); then it identifies the operations and classifies them as common or entity-specific: • Common — Active exchanges, Completed exchanges, Faulted exchanges, Error exchanges, Exchange duration, Throughput, Historical distribution of MEP by type; • NMR — Active Components, Active Endpoints; • Delivery Channel — Timing path information; Each operation is analyzed and the monitoring parameters are derived from it. It allows to provide a set of statistics at each level of the JBI abstraction. The Sierra framework monitors the following statistics for default: • Framework — StartTime, StartupTime, UpTime, Component count, Endpoint count, ServiceAssembly count; • NMR — Time spent in each component, Time spent in DeliveryChannel, Time spent in NMR Per Component/Endpoint Queried by Component/Endpoint; • Component — StartTime, StartupTime, UpTime, Total # of activated endpoints, Total sent/received requests (i.e. ”in” msgs), Total sent/received replies (i.e. ”out” msgs), Total sent/received faults, Total completed exchanges (consumed/provided), Total active exchanges (consumed/provided), Total error exchanges (consumed/provided) Response Time, Status Time, Active MessageId’s, Waiting MessageId’s; • Service Assembly — Uptime, Last startup timestamp, Startup time, Stop time, Shutdown time (Startup, Stop and Shutdown are also accessible per constituent Service Unit); • Endpoints — ActivationTime, UpTime, Total sent/received requests (i.e. ”in” msgs), Total sent/received replies (i.e. ”out” msgs), Total sent/received faults, Total completed exchanges (consumed/provided), Total active exchanges (consumed/provided), Total error exchanges (consumed/provided), Response Time, Status Time, Active MessageId’s, Waiting MessageId’s; Additional Service Assembly and Framework levels were introduced. The Framework is equivalent to OpenESB cluster abstraction. At the Framework level, the parameters can be queried in the context of the whole cluster or specific OpenESB instance. It results in the monitoring solution being in line with OpenESB clustering described in Section 3.3.4. Apart from the listed monitoring parameters, the Sierra monitoring has the functionality of recording message exchanges going through the Bus. This mechanism is not yet completely implemented, but final functionalities will allow to extract interesting message exchange data, including the timing path that will be described later. The message exchange history can be evaluated in two ways: • saving to a log file for later processing; • runtime results aggregation on the basis of dynamic or static conditions;


43

Timing path analysis and capability of dynamic aggregation will make historical records a great tool for solving performance issues. The Sierra monitoring has powerful functionalities which provide a complete view of the whole JBI bus. Presentation layer Presentation layer is not provided in the discussed monitoring mechanism. Instead, proper JMX interfaces are exposed. They are more flexible than the integrated presentation capability because JMX MBeans can be easily connected to and used for realization of any kind (stand-alone or webbased) user interface. Timing Path Sierra provides great details of performance analysis. MessageExchange communication has well-defined internals which are important compounds of general performance. To find the reason of poor performance of some MessageExchange, Sierra analyzes timing from both the consumer’s and provider’s point of view. Both approaches allow to find various points in JBI send()—accept() path, where important measurements can be done. Four main areas from consumer’s point of view have been identified. They are depicted in the following diagram 5 :

Consumer Provider -----------------------------------send()

--->+ | +------> accept() | | | + < s u f l a t name="name"> . . . . . . . . .

The operation is omitted in the topology information because it cannot be easily extracted from the ServiceUnit. Its support can be added later on. GlassBus persists XML in a regular file but thanks to the HierarchyDao abstraction it is not difficult to employ some hierarchical-relational DBMS. Messaging model In order to justify the messaging model, JBI Message Exchange Patterns (MEP) presented in the Diagram 6.4 will be discussed. Patterns are necessary for explaining the timing path introduced in Section 3.3.3.

6.3. Logical Structure

138

Figure 6.4: JBI Message Exchange Patterns. The image is taken directly from JSR-208.

The introduced timing path is recalled again below 1 : Consumer Provider -----------------------------------send() --->+ 1 | 2 +------> accept() | | 3 | +fallbackComponentConsumerProviderOperations NotificationListener listener , String instance ) ; void registerForFlowStats ( Map consumerProviderEndpoints , Map< String , String>fallbackComponentConsumerProviderEndpoints NotificationListener listener , String instance ) ; void deregisterFlowListener ( NotificationListener listener ) ;

29 30

31

32 33

void registerForTransStats ( String transactionPath , NotificationListener listener ); void registerForBusinessOpStats ( Map rootEndpointOperationPairs , ListfallbackComponentConsumer , NotificationListener listener , String instance ) ; void deregisterTransListener ( NotificationListener listener ) ;

The methods have been designed in a manner similar to those from other MBeans of the monitoring interface model - regular methods and notifications, which result in same XML-embedded statistics (with the addition of totalInvocations parameter). However, there are new list methods, which allow to acquire information about transactions (ME TRANS PATTERN) and business operations (BUSS TRANS) starting in a particular JBI element. The result of listBusinessOp encloses all root starting points of business operations. It is provided in XML with the following format: 1

2 3

4

... ...

The result of listTrans encloses transaction paths provided in XML with the following format: 1 2 3

4

5 6 7 8

... ...

The method queryTrans also allows to acquire a list of transaction paths, but the beginning of a transaction must be the same as the partialTransactionPath provided as argument of an XML file with the same format as the jbi transaction node presented above. The method allows to query transaction the starting part of which goes through some particular endpoints supplied in the query.


150

The methods registerForNew* provide a listener notification in case of new transactions or business operations appearing in a particular cluster scope. The methods getSubFlowStats and getFlowStats (also their notification equivalents) allow to acquire statistics about particular ME SUB FLOW PATTERNs and ME FLOW PATTERNs. Consumer of ME FLOW PATTERN can be also specified by means of the componentFallback name (used when the consumer’s endpoint is not acquirable), but it is optional. Method’s Map arguments allow to supply multiple values and therefore conduct an aggregation of the related ME SUB FLOW PATTERNs or ME FLOW PATTERNs. The getBusinessOpStats method (and its notification equivalent) allows to query statistics of whole business operations. The method provides the possibility of aggregation (thanks to Map and List arguments) and the option of supplying the consumer by means of the component’s name. The only method not equipped with aggregation is getTransStats (along with its notification equivalent), which allows to acquire statistics of a particular transaction (ME TRANS PATTERN). Transactions can only be aggregated by means of business operations that enclose them. Unfortunately, a transaction has to be specified through all compounding endpoints (and possibly through fallbackContainerName at the beginning) enclosed in an XML argument of the same format as the jbi transaction node presented above (reference to the schema).

6.3.5

Management and selectivity model

As it has been delineated before, GlassBus is not only the Monitoring solution. Its architecture allowed for providing a wide range of management features. Management, analogically to monitoring, is realized at several levels providing flexibility of adjusting GlassBus to particular needs and tuning the selectivity of gathering monitoring information. The problem with management comes from the distributed GlassBus architecture. It is easy to imagine a federation of fifty JBI containers instrumented with GlassBus. The management of such a widespread cluster is difficult not only in terms of adjusting the GlassBus Agent mechanism, but also in terms of managing the containers themselves. The GlassBus management architecture solves both problems. GlassBus Agents can be managed in two ways: • by JMX management interface; • by configuration files. Both mechanisms allow to control similar elements, but JMX management is equipped with broader functionalities, which is the reason for discussing it in the first place. The discussion of configuration is presented in one of next sections (6.5). In order to provide selectivity of the information gathering mechanism, several levels of data acquiring have been introduced: • TOPOLOGY — only the information about the bus topology is gathered by the Agent and forwarded to the Engine. The topology is additionally divided into inner levels of selectivity: – COMPONENT — only information about components is acquired (employing JBITopologyComponentInterceptor);


151

– SERVICE UNIT — information about components, service assemblies and service units is acquired (employing JBITopologyComponentInterceptor and part of JBITopologySUInterceptor); – ENDPOINT — information at all levels including endpoints and operations is acquired (employing both JBITopologyComponentInterceptor and JBITopologySUInterceptor); • MESSAGING BASIC — the topology information is enriched with messaging events, but no inter-message correlation is applied (employing all topology interceptors and JBIMessagingInterceptor); • MESSAGING COMPLETE — all acquirable information is gathered, including: topology, messaging along with correlation into jbi transactions (employing all topology, messaging interceptors and additionally correlation heuristics). The lowest possible monitoring level is TOPOLOGY with an inner COMPONENT level. JMX management of the Agent is realized by means of GlassBusAgentControlMBean, which is equipped with the following methods: • getGlobalSelectivityLevel; • getTopologySelectivityLevel; • setGlobalSelectivityLevel; • setTopologySelectivityLevel; The methods allow for a flexible adjustment of the GlassBus information monitoring. Another functionality of the GlassBusAgentControlMBean is forwarding JBI MBeans, which are defined in JSR-208. It means that a reference to those MBeans can be obtained through invocation of the GlassBusAgentControlMBean methods (the code is provided in Listing A.11). The following MBeans are obtainable: • AdminServiceMBean; • DeploymentServiceMBean; • InstallationServiceMBean; Thanks to the exposition of GlassBusAgentControlMBean to the Engine, all the above-listed selectivity levels and JBI MBeans can be managed from one central point - the GlassBus Engine. As depicted in the Engine’s class diagram (6.7), the GlassBusAgentControlMBean of each Agent is accessed by the GlassBusManagementMBean, which allows the Monitoring administrator to manage every Agent. As it has been mentioned at the beginning of this section, such a solution combines the capabilities of managing not only GlassBus Agent, but also the JBI Container itself. The GlassBus Engine can be used to install new components or deploy new service assemblies on distant JBI containers (for the functionalities of JBI MBean pleas refer to the JBI Status Quo 3.3 provided earlier).


152

Aspect weaving adjustment GlassBus installer instrumentation of the Agent is accompanied with the incorporation of all aspects into the JBI container. It implies that in the course of the container initialization all aspects are woven into the bus’s code. Therefore, setting a lower selectivity cannot disable pointcuts already woven. Instead, each pointcut is equipped with checking the selectivity level and on its basis performs a logic or abandons it. Such a solution results in the minimal performance impact in the case of lower selectivity levels. It has been decided that this mechanism is sufficient for the purpose of performance impact minimization, however the user of GlassBus may still be concerned about disabling weaving of the unwanted aspects. It can be simply achieved by means of a modification aop.xml file (A.8) which is embedded in the following jar artifacts: glassbusagent-smix and glassbus-agent-openesb. In the course of the modification modification, aspects dependencies have to be preserved: the heuristics rely on messaging, the messaging relies on topology.

6.3.6

Invocation flows

This section is devoted to discussing end-to-end flows of the three main GlassBus functionalities: registration, messaging and topology propagation. Every functionality is delineated in a separate UML activity diagram. The diagrams allow for a clear expression of dependencies between the logical structure elements and their interactions.


153

Agent registration

Figure 6.9: The Agent in the Engine registration sequence diagram

Agent registration, depicted in Figure 6.9 is crucial for the whole GlassBus operation. Neither messaging nor topology propagation can be realized without a successful registration. In order to join the monitoring domain of a particular Engine, the Agent needs to know its name a priori. The default name of the Engine is ”JbiMonitoringEngine”, but it can be adjusted in the component’s properties files (presented in Section 6.5). The Agent invokes registration in the GlassBusEngineRegisterMBean interface. The Engine verifies the Agent’s accessibility by means of GlassBusAgentControlMBean. Both interfaces are provided by Lingo’s JMX over JMS and are not released during the further Engine’s and Agent’s lifetime. They are used for a constant accessibility verification allowing for instant identification of problems with the Agent-Engine communication.


154

Messaging propagation

Figure 6.10: Messaging propagation sequence diagram

Messaging propagation, depicted in Figure 6.10, starts from the JBIMessagingInterceptor, which intercepts the sending and receiving of MessageExchanges. The Interceptor verifies the crosscut delivery channel in order to assure that it belongs to the component that has started, otherwise the event is ignored. After a successful verification, the event is passed to correlators for the transaction correlation. The correlators are incorporated by CorrelatorsExecutor (it is not depicted in the diagram), which allow for an easy future addition of new correlators. Further event and correlation information is passed to the Agent’s most important element - MessagingProcessor. The Processor checks the event context (sending, receiving) and enriches the MessageExchange’s properties with the information defined in the Domain model (6.3.1). If the event is not final for a particular MEP, the ME is returned to the interceptor and released. In the case of a final event which receives the JBI’s status (DONE or ERROR), the MessagingProcessor embeds the ME data (extracted from its properties and internal attributes) into the Messaging model and sends it out through the JMSSender. The JMS layer draws a line of demarcation between the Agent and the Engine, which is traversed from the JMSSender to the ReceiverMDP. The latter receives messages, verifies the sending Agent (checks whether the Agent has previously successfully registered and is available), notifies the statistics module and finally persists the data in GlassBusDao. The GlassBusStatistics maintains a registry about the external users registered for changes of particular monitoring pa-

6.4. Physical Structure

155

rameters and informs the users when it is appropriate. Topology propagation

Figure 6.11: Topology propagation sequence diagram

The topology propagation, depicted in Figure 6.11, is less complicated than the messaging propagation. Only six main entities are involved - the three that are left are of the Agent and the rest belong to the Engine. The diagram captures the fact that the interception of the component and ServiceUnit events are not related - they can even take place concurrently. The JBITopologyComponentInterceptor updates the register of the DeliveryChannelInfo (containing bindings between the components and their delivery channels), which has previously been presented in Messaging propagation the diagram. The rest of the flow is the same for both the JBITopologyComponentInterceptor and the JBITopologySUInterceptor. The border between the Agent and the Engine is traversed by means of the JMX over JMS layer - the methods of TopologyListenerMBean allow to propagate the intercepted topology changes. The TopologyListener performs further verification, notification of statistics module and finally persists the information in HierarchicalDao. By analogy to the messaging propagation, the GlassBusStatistics informs the external users when it is appropriate.

6.4

Physical Structure

It has been decided that Maven [43] will be used for the purpose of the GlassBus implementation structuring and building. Its hierarchical model allowed for a flexible arrangement of the GlassBus artifacts. Thhe Glassbus’s physical structure has been delineated in Figure 6.12 by means of a UML package diagram. The diagram provides a namespace of each artifact, which can be useful for the purpose of logging configuration.

6.4. Physical Structure

156

Figure 6.12: Physical structure of GlassBus implementation

It was predictable that two most important logical entities: the Engine and the Agent will also be major elements of the physical structure. Each artifact’s purpose is depicted in the following list: • glassbus-common — JMX MBean interfaces shared by the Agent and the Engine: GlassBusEngineRegisterMBean and GlassBusAgentControlMBean. • glassbus-dao — JPA entity beans used for the purpose of persisting the information in the Engine. Dao is also used for transferring information between the Agent and the Engine. • glassbus-agent — It is divided into the core part, which covers all implementation, and additional artifacts, which personalize the Agent for a particular JBI bus. Currently, the openesb and smix artifacts enclose only the aop.xml file, which properly configures the aspects provided in the core artifact. In order to support an additional bus, a new artifact of glassbus-agent-jbibus has to be added. • glassbus-engine — similarly to the Agent, the core part is identified, which covers all the Engine’s implementation. The following two artifacts provide support for deployment scenarios: out-of-the-box and application server. Depending on the requirements, the box or war variant has to be used for installation.

6.5. Configuration

157

• glassbus-installer — the installer combines all other artifacts and allows for an easy installation in any kind of a deployment scenario. • glassbus-externaliface — it is a small library which encloses external interfaces of the MBean statistics: GlassBusPatternStatsMBean, GlassBusPointStatsMBean and GlassBusTopologyMBean. It can be employed by the Monitoring administrator’s JMX client for easier access to the monitoring interface. The clear-cut separation of the artifacts’ functionalities provides the ease of extending GlassBus to other JBI compliant buses. The hierarchical structure allows to perform incremental builds of parts of the system without influencing other elements. All complexity of compilation - processing the aspect files and assembling them into jars along with the rest of the code - is covered by maven, which also allows for a complete specification of each artifact’s dependencies. Project configuration is enclosed in each artifact’s pom.xml file and does not require any modification. In order to build a project after code modifications, it is sufficient to invoke the mvn install command, which takes care about everything. The created glassbus-installer has to be propagated to desired JBI containers. After that, the GlassBus monitoring system is fully functional and ready to use.

6.5

Configuration

As mentioned earlier, configuration files are another way of managing the Agent. Being more precise, the configuration files are used not only on the Agent, but also on the Engine. They are related not only to management, but also to some regular parameter supplication. GlassBus is configured through two files: general properties and detailed broker XML. General configuration General configuration is enclosed in the properties files, which have the following names in the Agent and the Engine respectively: glassbus-agent.properties and glassbus-engine.properties. They are accessed through the Configuration class, which has been presented on the Agent’s and the Engine’s class diagrams. The glassbus-agent.properties file has the following content: 1 2 3 4

glassbus . clusterName=JbiCluster glassbus . monitoringEngineName=JbiMonitoringEngine glassbus . instanceName=JbiAgent1 glassbus . startingOwnBroker=false

5 6 7

glassbus . globalSelectivity=MESSAGING\_COMPLETE glassbus . topologySelectivity=ENDPOINT

8 9

activemq . brokerName=localhost

10 11

lingo . jmxJmsResponeTimeout=20000

The Agents and the Engine belonging to the same JBI cluster have to be configured with the same clustername. The monitoringEngineName is used for addressing the initial in-engine registration, where the instanceName is provided as the Agent’s name. The startingOwnBroker and

6.5. Configuration

158

activemq.brokerName are related to particular deployment scenarios - they will be discussed in the next section. The lingo.jmxJmsResponeTimeout allows to tune the timeout of JMX over JMS invocations. It defaults to 20 seconds. The selectivity parameters (described in 6.3.5) allow to set up its initial values. Configuration of the GlassBus Engine is similar but it obviously does not have the monitoringEngineName and selectivity values can be configured separately for each Agent’s name: 1 2 3 4

glassbus . AGENT1 . globalSelectivity=VALUE glassbus . AGENT1 . topologySelectivity=VALUE glassbus . AGENT2 . globalSelectivity=VALUE glassbus . AGENT2 . topologySelectivity=VALUE

It allows to override settings from the Agent’s configuration. As soon as the Agent registers in the Engine, its selectivity is set to the values provided in the glassbus-engine.properties. Broker configuration Broker configuration is related to the middleware realized by the ActiveMQ messaging solution. Configuration of all broker’s usage cases is out of the scope of this thesis and can be found in the ActiveMQ documentation. This section is restricted to the configuration of the GlassBus’s deployment scenarios presented in Section 5.10.2. Out-of-the-box This scenario is realized by means of only one broker instance. Therefore, no additional configuration is needed. The tags transportConnectors and networkConnectors can be commented out because every GlassBus element accesses the broker internally through JVM. In a general configuration, the activemq.brokerName can be set to any value (it defaults to localhost) and the value of the startingOwnBroker has to be set accordingly to the specific bus: ServiceMix has its own broker, which is why there is no need for starting another one, contrary to OpenESB, which is not equipped with a broker. Distributed cluster The distributed cluster allows for several instances of Agents and one Engine instance. Each broker has to set up its own transportConnector, which has to be referred to in the networkConnectors section of all other cluster nodes. A sample configuration with two Agents could have the following shape: 1 2 3 4 5 6 7 8 9 10 11 12 13 14

AGENT1: −−> −−> AGENT2: −−>

6.6. Installation

15 16 17 18 19 20 21 22 23 24

159

−−> ENGINE: −−> −−>

In a general configuration, each node has to have unique value of activemq.brokerName. The same uniqueness is required for the instanceName parameter. The property startingOwnBroker has to be analogical to the one in the out-of-the-box scenario.

6.6

Installation

Assumptions about GlassBus Installer realization were provided in Section 5.10. This section covers detailed installation instructions. As delineated in Section 5.10, the GlassBus installer is provided as an executable jar. It encloses every GlassBus components apart from the glassbus-engine-war, which is a separate WAR artifact. The GlassBus WAR package can be downloaded and deployed to the Application Server independently from the GlassBus installer. Detailed instructions of the WAR deployment depend on a particular Application Server and are simple enough to be covered by the user himself/herself. In order to use the GlassBus installer, its jar has to be downloaded and executed. The installer should be executed in a root directory either of the ServiceMix or a particular domain of the OpenESB’s application server. Alternatively, a destination path can be supplied with the -p argument. After executing the installer, an interactive process of choosing various options begins. It is depicted in the following listing: 1 2 3

I . Provide a JBI container which is glazed by GlassBus: 1 ) ServiceMix 2 ) OpenESB

This step is often omitted because the installer can automatically detect a particular bus thanks to the analysis of its root directory. The next steps are as follows: 1 2

II . Instrument the bus with GlassBus Agent? [ y/n ] III . Instrument the bus with GlassBus Engine − out−of−the−box scenario? [ y/n ]

Answering these simple questions allows to complete the installation process. A particular JBI container is glazed by GlassBus and after some simple configuration - 6.5 (in the out-of-the-box scenario no additional configuration is needed), the JBI monitoring solution is ready to be used. The installation process can be performed in a non-interactive manner by the -c argument provided, which is followed by a path to the installation property file configuration. The file has to have the following format: 1

jbiContainer=CONTAINER

6.7. Implementation status

2 3

160

glassbusAgent=Yes/No glassbusEngine=Yes/No

It allows to perform GlassBus deployment on a large scale (big JBI clusters) in an automated manner. If the installer is invoked with the -u argument, uninstallation of a particular GlassBus component can be performed. The interactive and non-interactive uninstallation process is analogical to the installation one.

6.7

Implementation status

In the course of the work on this thesis, it turned out that creating a complete architecture for the JBI monitoring solution is not an easy task. The contradiction between the requirement of a fully JBI compliant bus and the requirement of ServiceMix and OpenESB support in terms that are beyond the JBI scope (i.e. clustering), resulted in an architecture of a high complexity level. The wide range of solved problems discussed in Chapter 5 provides a good complexity estimation, which is verified by the completeness of the final functionalities described in Chapter 6. Such a GlassBus evolution resulted in restricting the implementation of a system with a production quality. The GlassBus design presented in this thesis has been based on a complete set of Proof Of Concept [106] implementations, which allowed to verify every architectural decision. As the fully functional implementation of GlassBus with a production quality is out of the scope of this thesis, it has been decided to provide only the research version of GlassBus. This version focuses on validating both the out-of-the-box and the distributed scenarios, but not in all cases. End-to-end flow of information is provided in each case (registration, topology propagation, messaging propagation) but without a complete implementation of the Engine’s GlassBusStatistics class, which comes to simple operations on the persisted data. The RCP GUI has been identified as a complex feature that was not essential. The implementation of the JMX external monitoring interface was entirely sufficient for the research, therefore a GUI has not been provided. It can be conceived that the research version of GlassBus is a fully functional skeleton but not a complete production system. The skeleton solves all crucial problems in an innovative way, leaving the regular implementation of well-known elements in scope of future GlassBus’s work.

6.8

Performance Tests

In order to validate the GlassBus solution, some performance tests have been conducted. The crucial issue, which has driven the architectural decisions, is the influence on the JBI container’s performance. That was the reason for decoupling Agent instrumentation from Engine processing and analysis. The deep analysis of JMSSender performance and choosing high-performance messaging middleware solution - ActiveMQ allowed to minimize the overhead on the Agent’s side. The research version of GlassBus does not provide all functionalities of the Engine’s statistics, but it is not an obstacle for performance tests which focus on the GlassBus Agent’s influence on ServiceMix and OpenESB.

6.8. Performance Tests

161

The tests verified the difference between regular non-instrumented bus operation performance and the performance after GlassBus installation. The following GlassBus’s elements were in the scope of the performance measurement: • topology interceptors; • messaging interceptor; • thread correlation heuristic; • agent’s MessagingProcessor; • agent’s JMSSender. In order to perform tests that give good performance estimation, the business logic of services deployed to the JBI container has been minimized. A small logic overhead allowed to focus on the performance of communication, which is the main subject of the GlassBus influence. In the cases of both ServiceMix and OpenESB, the business logic was a simple echo application exposed by the Binding Component. During the tests, the selectivity of GlassBus Agent was set to the highest possible value: MESSAGING COMPLETE. The test has been performed in two deployment scenarios (cf. 5.10), which are further divided into sequential and concurrent cases: • Out-of-the-box — The Agent and the Engine are embedded into the non-distributed bus, which allows to share a common broker instance and avoid external communication. – Sequential — 100 000 sequential invocations of endpoint exposed in BC; – Concurrent — 10 000 invocations of BC’s endpoint in 10 concurrent threads; • Distributed — There is one instance of a non-distributed bus instrumented with the GlassBus Agent and a separate node with the GlassBus Engine. The nodes are in the same local network. This scenario is analogically divided into the sequential and concurrent case. The goal of a particular test was to measure the mean duration of business operation execution. Business operation is exposed by a binding component, which is invoked by an external code of the tester. The tester performs appropriate measurements: calculation of mean and its standard deviation over all invocations. The number of invocations that will be the subject of the mean calculation was already provided: 100 000 invocations in the sequential case and 10 000 invocations performed by 10 threads in the concurrent case.

6.8.1

Test environment

The following hardware-software environment was used for the purpose of the performance tests: Node for Box scenarios and for the GlassBus Agent in the distributed scenario: Processor: Intel(R) Core2 Duo T5600 1.83GHz, 2MB Cache L2, FSB 667MHz Ram: 2GB DDR II Hardware: 100 GB SATA150 5400 rpm


162

Networking: LAN 100 MBit OS: Ubuntu 7.10 (Gutsy Gibbon) Server version Node for the GlassBus Engine in the distributed scenario: Processor: Intel(R) Core Duo T2310 1.46GHz, 2MB Cache L2, FSB 667MHz Ram: 1GB DDR II Hardware: 100 GB SATA150 5400 rpm Networking: LAN 100 MBit OS: Ubuntu 7.10 (Gutsy Gibbon) Server version In order to minimize interferences, these two nodes have been disconnected from the global Internet network. For the purpose of the distributed scenario, the nodes were interconnected with a regular 100 MBit Local Area Network. The operating system installed on both nodes was properly prepared: all not related daemons and applications were disabled, leaving only the basic networking functionalities.

6.8.2

ServiceMix

Simple ServiceAssembly with HTTP binding component and JSR-181 service engine were used in ServiceMix. SA’s topology has been delineated in Figure 6.13. In the distributed scenario, the first node was equipped only with the GlassBus Agent, while the second node encompassed the GlassBus Engine embedded into another ServiceMix instance (using the out-of-the-box feature).

Figure 6.13: ServiceMix topology for performance tests

The results of the ServiceMix performance tests are depicted in Table 6.2. The results provide information about mean duration of a single BC invocation, given in milliseconds.

Table 6.2: Performance of glazed ServiceMix

Scenario Without GlassBus GlassBus Box GlassBus Distributed

Sequential Mean Std. Dev. 26.04 ms 2.78 ms 30.78 ms 4.58 ms 29.40 ms 2.60 ms

Concurrent Mean Std. Dev 120.49 ms 2.91 ms 152.41 ms 0.74 ms 144.52 ms 1.74 ms

The results show that the GlassBus instrumentation implies some overhead. The exact overhead percentage is presented in Table 6.3. The overhead was calculated according to the following ithoutGlassBus ∗ 100% formula: Overhead = DurationW ithGlassBus−DurationW DurationW ithoutGlassBus


163

Table 6.3: GlassBus overhead in ServiceMix

Scenario Box Distributed

Sequential 18.2% 12.9%

Concurrent 26.5% 19.9%

It can be observed that the distributed scenario tends to outperform the out-of-the-box scenario. Another observation related to the concurrency influence is that, as suspected, it leads to a higher GlassBus overhead. Further conclusions are provided in the summary.

6.8.3

OpenESB

A simple ServiceAssembly has also been used in the case of OpenESB. It encompassed a HTTP binding component and a J2EE service engine. The SA’s topology is delineated in Figure 6.14. The distributed scenario was covered similarly to ServiceMix - the GlassBus Engine was embedded into a second OpenESB instance (out-of-the-box feature), installed on the second node. In both scenarios, OpenESB was executed in the Application Server’s environment (GlassFish).

Figure 6.14: OpenESB topology for performance tests

The results of OpenESB performance tests are depicted in Table 6.5. The results provide information about mean duration of a single BC invocation, given in milliseconds.

Table 6.4: Performance of glazed OpenESB

Scenario Without GlassBus GlassBus Box GlassBus Distributed

Sequential Mean Std. Dev. 6.69 ms 1.42 ms 7.62 ms 1.33 ms 7.14 ms 0.52 ms

Concurrent Mean Std. Dev 56.99 ms 1.78 ms 68.35 ms 1.48 ms 64.99 ms 2.12 ms

Similarly to ServiceMix, there is an overhead implied by GlassBus. The exact overhead percentage is presented in Table 6.5. The overhead was calculated in the same way as in ServiceMix.

Table 6.5: GlassBus overhead in OpenESB

Scenario Box Distributed

Sequential 13.9% 6.7%

Concurrent 19.9% 14.0%


164

The OpenESB performance tendencies are similar to those of ServiceMix: the distributed case outperforms the out-of-the-box one, concurrent invocations imply more overhead than the sequential ones.

6.8.4

Summary

Comparison of the ServiceMix and OpenESB overhead is depicted in Figure 6.15.

Figure 6.15: Comparison of GlassBus performance overhead

The following tendencies have already been noticed earlier: • The distributed case outperforms the out-of-the-box scenario - It is suspicious at first glance, but a deeper analysis confirms it. In the case of the box scenario, the node is additionally loaded with the GlassBus Engine logic, which is moved to the second node in the distributed scenario. While distributed, the Agent simply passes the information about MEP to the ActiveMQ broker for send-out. It is less demanding for the processor. • Concurrent invocations are the reason for a higher overhead - The reason for this lies in the bottleneck of the broker. Suddenly, there are more messages forwarded to the Engine, which all have to go through one broker of the GlassBus Agent. The analysis of the chart presendted above allows to make further conclusions. The GlassBus overhead measured in OpenESB is lesser than that of ServiceMix. It is difficult to point out the reason for that - probably the internal implementation of OpenESB is better suited for the AOP crosscuting. The most important observation is that the maximal GlassBus overhead is only 25%

6.9. Conclusion

165

(Concurrent Box of ServiceMix) and it is the only case of exceeding the overhead to more than 20%. It has to be stressed that the tests were intentionally performed on an empty business logic. In real JBI usage scenarios, the business logic is probably much heavier, which will result in a lower overhead of GlassBus. It can be concluded that the GlassBus’s overhead is acceptably low. It is an affordable cost of having monitoring/management systems with such a wide scope of functionalities.

6.9

Conclusion

The GlassBus Implementation chapter is an important supplement of the previous one, which provided justification for architectural design decisions, giving good background for logical and physical structure information enclosed here. The chapter contains many important information, which is significant for understanding GlassBuss capabilities. Along with the domain messaging model, an analysis of the JBI Message Exchange Patterns timing path is performed. It has been concluded that the most important timing information is related to the processing time (part 3 of timing path), which allows to monitor performance of the logic execution and also propagation of the fault and status. In the description of the GlassBus Agent and the GlassBus Engine, focus was put on identification of inter-component interfaces. Thanks to that the three main scenarios described on the invocation flows - agent registration, topology propagation and messaging propagation are more lucid. Next very important section is the External monitoring interface (6.3.4). It contains a definition of interfaces exposed by GlassBus. The interface related to the topology is not complex - its structure does not extend the topology model introduced earlier. The Messaging interface is related to many statistics and therefore it is less trivial. The abstraction model is introduced in order to demystify the semantics and methods from the external interface of messaging. It is supplemented by details of the Pattern messaging interface introduced on the basis of illustrated definitions of GlassBuss notions provided in Section 4.4. As it has been concluded in Chapter 3, a monitoring system is unusable without proper selectivity and management. Proper facilities have been introduced and described in Section 6.3.5. Unfortunately, the high complexity of the JBI monitoring subject and the completeness of the GlassBus solution made it impossible to provide a fully functional and complete implementation - it is justified in Section 6.7. Fortunately, the performance tests prove the correctness of the GlassBus architecture and assure that a full implementation is realizable.

Chapter 7

Conclusions Victory has a thousand fathers, but defeat is an orphan. John F. Kennedy, American Statesman and 35th U.S. president.

7.1

Overview

The main goal of this thesis was to provide a usable solution capable of monitoring systems compliant with JSR-208 specification, i.e. implementations of Java Business Integration. Focus has been put on the OpenESB and ServiceMix solutions, which at the beginning of the work on this thesis were the main projects that supported the specification. The main JBI concepts have been presented in the second chapter (2), starting from a general subject of enterprise integration, going through the definitions of Enterprise Service Bus and finally identifying the JBI container as an attempt of ESB standardization. As it turned out later in the third chapter (3), JBI does not strictly conform to all ESB assumptions. It lacks the standardization of clustering and distribution, which are essential for the concept of ESB federations. Nevertheless, it has been decided to fully support the features of ServiceMix and OpenESB. The analysis of the JBI status quo and theorems related to the application monitoring in the third chapter proved the JBI monitoring to be a significant challenge, which has been accepted by the authors of this thesis. The proper requirements with the division into functional and non-functional have been stated in the fourth chapter (4), giving a more precise projection of the GlassBus goals. The most important part of the GlassBus system description has been enclosed in the fifth chapter (5). Fortunately or not, the authors were forced to make a set of experiments which evaluate several possible realizations of a given system’s elements and finally to decide on the best possible solution. Each of these experiments is introduced as a separate section of the fifth chapter (5). Throughout the evaluation of the experiments, all requirements from the fourth chapter (4) were constantly being referred to, which allowed to choose the realizations maintaining compliance with the functional and non-functional goals of GlassBus. It has to be admitted that reviewing the requirement compliance tables provided in the fifth chapter (5) leads to the conclusion that all GlassBus goals have been achieved. Of course, the high complexity of the solution, which is further described in the sixth chapter (6), did not allow to implement a fully functional production system. Instead, a research version of GlassBus has been provided which is a fully functional skeleton of the JBI monitoring solution. Therefore, it can be summarized that all goals of the architecture design have been achieved, but not all of them have been implemented. Their implementation has been postponed for future work on the GlassBus system.

7.2. The status of Java Business Integration

7.2

167

The status of Java Business Integration

Future applicability of GlassBus depends heavily on the status of JBI itself. When the JBI emerged in August 2005, it was a promising attempt of ESB standardization, which was identified as having the potential of changing the balance of the enterprise solution market. Unfortunately, early on two most important partners of expert group: IBM and BEA backed off from supporting JBI. Fortunately, heavy support of Sonic, TIBCO and Sun allowed to overcome these initial difficulties and to provide a solution changing the face of ESB. It is difficult to objectively judge the success of JBI. There are many users who are satisfied with JBI incorporated in their enterprise infrastructure. There are, however, also some critical opinions. In the article of Darryl K. Taft, Mark Little, director of Standards and JBoss ESB, justifies the JBI problems in the following way: ”It was a bit too early (...) It got caught up in the Web services hype of 2005 when Web services was a big selling point of J2EE.” [98]. Another negative opinion given by an anonymous observer is the following: ”JBI 1.0 was not ready for prime time; it focused on vendor needs and not the user, and has been a miserable failure. This is why you saw BEA and IBM, for instance, walk away and do SCA [Service Component Architecture]. If someone wants to write an ESB app today, it will not be portable to other ESBs. We think this is a horrible situation to put customers in, when SOA is about reusability, interoperability and flexibility.” [98]. Recently, it has turned out that JBI has to face a new trend of inclining towards more lightweight solutions. The reason for this lies in the increasing quality of the solutions providing a partial ESB mechanism. Every Enterprise Bus encompasses: messaging backbone, orchestration engine and some binding connectors. Currently, there are many solutions which can be recommended for the realization of those ESB elements. For example, Artur Karazniewicz in his comment on LinkedIn portal [89] recommends the following combination: ”JAX-WS and JAXB as a SOAP connectivity, Active MQ as a messaging backbone, Apache Camel as a orchestration engine and Spring to glue it all”. Such a combination can be successfully used as a comprehensive and feature-rich Enterprise Service Bus substitution, which reveals the fact that it is not difficult to achieve functionalities similar to ESB or JBI without a heavy bus infrastructure. Such a tendency naturally leads to questioning the need of JBI.

7.3

Future of JSR-208 - JBI 2.0

In order to tackle the JBI shortcomings, the creation of a new version of the specification was initiated in the form of Java Specification Request 312 [4]. Unfortunately, JBI 2.0 along with its predecessor has been identified as competitive to the Service Component Architecture [44]. SCA is based on a composite application model and, contrary to JBI, it is multi-lingual: Java, C++, Spring, PHP, Ruby, WSDL are supported. It is commented as a ”new programming model for creating service-oriented components in Java (and C++), and a way to describe how components are assembled into groups called composites” [99]. The SCA alternative is the reason for sustaining the lack of JBI 2.0 support by BEA: ”We remain unconvinced of the value of a Java-only solution for SOA (...) BEA believes that the Java community will be better served with a multiplatform, multi-language SOA standard like SCA than anything that can be developed solely for Java. As such, we would prefer that a new JBI expert group not be formed.” [98]. The situation is similar - BEA and IBM deny supporting JBI initiative. This time, however,

7.3. Future of JSR-208 - JBI 2.0

168

the specification is created with an approach that will hopefully overcome the lack of this vital support. First of all, the aim of JBI 2.0 is not to compete with SCA, but to enhance its architecture [99]: • JBI can provide the key features for a runtime platform for SCA; • There is very little overlap; • JBI containers should be able to consume the SCA metadata; • The tools should be able to take the SCA composite definitions and create JBI Service Assemblies and Service Units. Such an approach rejects the BEA arguments against JBI. Additionally, according to Peter Walker’s presentation from June 2007 [99], JBI 2.0 answers many shortcomings of JSR-208 by introducing important features: Maintain definition of JBI for Java SE, Interceptors, Standard interfaces for expected services, POJOs as JBI components, Runtime Management enhancement, Clustering/distribution, Fault tolerance and reliability. From the GlassBus’s point of view, what is most important is the standardization of clustering, which has been mentioned several times as a significant problem and the reason for incompatibilities between ServiceMix and OpenESB. The second feature of great importance is the mechanism of interceptors. It is defined the in following way: ”Interceptors provide the ability to affect the processing of a message exchange without code and configuration changes (...) Interceptors offer an opportunity to address cross-cutting concerns in JBI architecture” [99]. The mechanism of interceptors has been identified as being very similar to GlassBus’s mechanism of gathering monitoring information, which is based on the AOP crosscutting. A hypothesis can be stated that the standardization of clustering and the interceptors mechanism could allow for an easy integration of GlassBus with JBI 2.0-compliant container. Of course, the hypothesis will be verified when JBI 2.0 is released. Unfortunately, since April 2007 there has been no update on the JSR-312 homepage. Taking account of the critical opinions about JBI 1.0, the developers of JBI containers are more cautious and try to provide a broader scope of functionalities which cover both SCA and the upcoming JBI 2.0. For example, ServiceMix 4.0 release is commented in the following way: ”The main focus is ease of use: while ServiceMix 3.x has mainly focused on JBI 1.0, the 4.0 version will go further and really leverage the good in JBI 1.0, while getting around the difficult parts to provide a flexible, powerful and easy API (...) ServiceMix 4.x also aims to support JBI 2.0 and SCA, so we will try to understand at how they can be leveraged together.” [87]. JBI 2.0 gives hope for mitigating the drawbacks of its predecessor and proving that the standardization of ESB is possible and beneficial. Watching the enterprise market reveals the fact that some ESB implementations are backing off from JBI compliance. However, new versions of the most popular JBI container evaluated in this thesis: ServiceMix 4.0 and OpenESB 2.0 plan to sustain the JBI support. It is definitely good news for GlassBus. Its architecture is flexible and lacks assumptions, which would made GlassBus’s evolution towards these new JBI container versions impossible. This conclusion along with the market trends and directions of JBI containers’ evolution suggests that a distributed JBI 2.0 container should be the primary focus of future GlassBus work. It would be also wise to take into account some extension towards SCA, which would boost the potential of GlassBus innovation.

7.4. GlassBus achievement

7.4

169

GlassBus achievement

The GlassBus challenge turned out to be really demanding. Great amount of work was needed in order to provide a solution compliant with all stated requirements. The quantity of work can be estimated by the statistics depicted in Table 7.1 and 7.2.

Table 7.1: GlassBus effort perspective

Number of classes Number of code lines Number of configuration lines Number of methods crosscut through AOP Number of external libraries used Number of months of constant work

67 4181 2979 28 39 9

Table 7.2: Proof-of-Concept projects effort perspective Number of PoC projects 8 Number of classes 152 Number of code lines 3734 Number of configuration lines 4837 Number of external libraries used 151

In the end, it turned out that putting so much effort has been well worthwhile. Despite some shortcomings of JBI specifications, a functional and innovative realization of JBI monitoring solution has been possible. All GlassBus goals stated in the executive summary have been achieved. There are some imperfections of the correlation heuristics related to assumptions about the processing of JBI message exchanges that are not always true. It was the cost of the high JBI compliance, which was one of the most important requirements. There was always a possibility of breaking the compliance and constructing a deterministic mechanism, but it would have to be proprietary to either ServiceMix or OpenESB. This would not be pure JBI monitoring anymore. As mentioned before, providing a fully functional implementation was impossible due to the high subject complexity. However, the GlassBus skeleton which has been delivered was capable of evaluating all crucial performance issues. The performance tests (6.8) assured that GlassBus has a minor influence on the JBI container’s performance. This suffices the most important requirement and ensures GlassBus’s success not only in the field of JBI 1.0, but also in the near future of JSR-312. GlassBus success can be verified by proving the truth of the thesis statement defined in the introduction. After all dissertation steps: theoretical foundation, requirements formulation, research, implementation, experimental verification, the thesis statement can be reformulated in the following way: The GlassBus processing model resulted in the construction of a system that adds monitoring and management logic to a Java Business Integration container, in such a way that the logic is fully transparent and

7.4. GlassBus achievement

170

compliant with the JBI specification. GlassBus allows to gather, process and expose sophisticated information regarding the qualitative parameters and operational reliability of the JBI container.

Appendices

Appendix A

Source code This appendix contains source code extracts from various GlassBus elements and from accompanying proof of concept efforts. Listing A.1: OpenARM colleration evaluation 1

public class Arm40BasicExampleOpenArm {

2 3 4 5

ArmApplicationDefinition armAppDef ; ArmApplication armApp ; ArmTransactionDefinition armParentTranDef ;

6 7

private ArmTransactionDefinition armChildTranDef ;

8 9 10

private static final Logger logger = Logger . getLogger ( Arm40BasicExampleOpenArm . class ) ;

11 12 13 14 15 16

static { BasicConfigurator . configure ( ) ; logger . getLoggerRepository ( ) . setThreshold ( "ALL" ) ; logger . info ( "[initializeLogging] Configured!" ) ; }

17 18 19 20 21 22 23

24 25 26 27 28

private static OpenArmConfiguration obtainOpenArmConfiguration ( ) { return new OpenArmConfiguration ( ) { public Map getMediatorConfigurations ( ) { final Map result = new HashMap ( ) ; result . put ( "net.m2technologies.open_arm.transport.transaction.logging. LoggingMediator" , new LoggingMediatorConfiguration ( ) ) ; return result ; } }; }

29 30

private OpenArmTransactionSimpleFacade openArm ;

31 32 33 34 35

/∗ initialize factories , ARM definitions and an ARM application instance ∗/ void armRegisterAndInit ( ) { this . openArm = new OpenArmTransactionSimpleFacade ( obtainOpenArmConfiguration ( ) , "JExamples" ) ;

36 37 38

armParentTranDef = openArm . getArmTransactionDefinition ( "JExampleParentTx" ) ;

173 armChildTranDef = openArm . getArmTransactionDefinition ( "JExampleChildTx" ) ;

39 40

}

41 42

public void run ( ) { armRegisterAndInit ( ) ;

43 44 45

ArmTransaction armParentTran = openArm . getArmTransactionMonitor ( armParentTranDef ) ;

46 47 48

armParentTran . start ( ) ;

49 50

int childStatus = ArmConstants . STATUS_GOOD ; if ( ! childTransaction ( armParentTran . getCorrelator ( ) ) ) childStatus = ArmConstants . STATUS_FAILED ;

51 52 53 54

armParentTran . stop ( childStatus ) ;

55

}

56 57

/∗ ∗ In−process nested transaction . The return value signals successful ∗ completion status . ∗/ private boolean childTransaction ( ArmCorrelator correlator ) { ArmTransaction armChildTran = openArm . getArmTransactionMonitor ( armChildTranDef ) ;

58 59 60 61 62 63 64 65

armChildTran . start ( correlator ) ;

66 67

armChildTran . stop ( ArmConstants . STATUS_GOOD ) ;

68 69

return true ;

70

}

71 72

}

Listing A.2: JMS sender proprietary implementation 1

package pl . edu . agh . glassbus . agent . sender ;

2 3

import java . io . Serializable ;

4 5 6 7 8 9 10 11 12

import import import import import import import import

javax . jms . ConnectionFactory ; javax . jms . JMSException ; javax . jms . Message ; javax . jms . Queue ; javax . jms . QueueConnection ; javax . jms . QueueSender ; javax . jms . QueueSession ; javax . jms . Session ;

13 14 15 16

/∗∗ ∗ S i m p l e s t and f a s t e s t implementation o f t h e JMS sender l o g i c ; ∗

174

17 18

∗/ public class JmsSender {

19 20

private ConnectionFactory cf ;

21 22

private String destinationName ;

23 24

private boolean sessionTransacted ;

25 26 27 28

public ConnectionFactory getConnectionFactory ( ) { return cf ; }

29 30 31 32

public void setConnectionFactory ( ConnectionFactory cf ) { this . cf = cf ; }

33 34 35 36

public String getDestinationName ( ) { return destinationName ; }

37 38 39 40

public void setDestinationName ( String destinationName ) { this . destinationName = destinationName ; }

41 42 43 44

public boolean isSessionTransacted ( ) { return sessionTransacted ; }

45 46 47 48

public void setSessionTransacted ( boolean sessionTransacted ) { this . sessionTransacted = sessionTransacted ; }

49 50

public void send ( Serializable object ) throws JmsSenderException {

51 52 53 54 55

QueueConnection queueConnection = null ; QueueSession queueSession = null ; QueueSender queueSender = null ; Queue queue = null ;

56 57 58 59 60 61 62 63

try { // g e t pooled connection , s e s s i o n and sender queueConnection = ( QueueConnection ) cf . createConnection ( ) ; queueSession = queueConnection . createQueueSession ( sessionTransacted , Session . AUTO_ACKNOWLEDGE ) ; queue = queueSession . createQueue ( destinationName ) ; queueSender = queueSession . createSender ( queue ) ;

64 65 66

// c r e a t e message with s e r i a l i z e d o b j e c t Message message = queueSession . createObjectMessage ( object ) ;

67 68 69

// send message queueSender . send ( message ) ;

175

70

// commit s e s s i o n i n c a s e o f t r a n s a c t i o n if ( sessionTransacted ) queueSession . commit ( ) ;

71 72 73 74

} catch ( JMSException e ) {

75 76

throw new JmsSenderException ( e . toString ( ) ) ;

77 78

} finally { // r e l e a s e r e s o u r c e s try { queueSender . close ( ) ; } catch ( JMSException e ) { // l o g t h e e r r o r } catch ( NullPointerException e ) { // l o g t h e e r r o r } try { queueSession . close ( ) ; } catch ( JMSException e ) { // l o g t h e e r r o r } catch ( NullPointerException e ) { // l o g t h e e r r o r } try { queueConnection . close ( ) ; } catch ( JMSException e ) { // l o g t h e e r r o r } catch ( NullPointerException e ) { // l o g t h e e r r o r } }

79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102

}

103 104

}

Listing A.3: Broker persistence configuration 1 2

3 4

(...)

5 6 7

8 9 10 11 12 13

176

14

15

16 17 18 19

−−>

20 21 22 23 24 25 26 27 28 29 30 31 32 33

−−>

34 35

36 37

38 39 40 41 42 43 44

−−>

45 46

47 48

49 50 51 52 53 54 55 56 57

−−>

58 59

177

60 61 62 63 64 65 66

−−>

Listing A.4: GlassBus Agent messaging interceptor 1 2 3

4 5

6 7

8 9 10 11 12 13 14 15 16

/∗∗ ∗ ∗ J B I M e s s a g i n g I n t e r c e p t o r uses p o i n t c u t s on a l l e n t r y p o i n t s t o DeliveryChannel ∗ t o i n t e r c e p t a l l MessageExchanges t h a t go through t h e channel . I n t e r c e p t e d ∗ MessageExchanges a r e passed t o JBIMessagingAnalyzer f o r a n a l y s i s and l o g g i n g . ∗ ∗ I t i s a b s t r a c t a s p e c t because o f pushAccept p o i n t c u t which l e a v e s possibility ∗ t o extend and i n t e r c e p t MessageExchanges a c t i v e l y pushed i n t o t h e ∗ DeliveryChannel . Hence t h e a c t i v e push i s not J B I compliant i t can be ∗ f l e x i b l e turned on/ o f f using t h e aop . xml . ∗ ∗ @author r o t g i e r ∗ @version 1 . 0 ∗ ∗/ public abstract aspect JBIMessagingInterceptor {

17 18 19

private static final Log log = LogFactory . getLog ( JBIMessagingInterceptor . class ) ;

20 21 22 23

/∗ ∗ JBI Pointcuts definitions ∗/

24 25 26 27 28

/∗∗ ∗ P o i n t c u t s t h e void a c c e p t ( ) method o f DeliveryChannel ∗/ pointcut accept ( DeliveryChannel deliveryCh ) : execution ( javax . jbi . messaging . MessageExchange accept ( ) ) && target ( deliveryCh ) ;

29 30

pointcut acceptTimeout ( long timeoutMS , DeliveryChannel deliveryCh ) : execution ( javax . jbi . messaging . MessageExchange accept ( long ) ) && target ( deliveryCh ) && args ( timeoutMS ) ;

31 32

pointcut send ( MessageExchange me , DeliveryChannel deliveryCh ) : execution ( void send ( MessageExchange ) ) && target ( deliveryCh ) && args ( me ) ;

33 34

35

pointcut sendSync ( MessageExchange me , DeliveryChannel deliveryCh ) : execution ( boolean sendSync ( MessageExchange ) ) && target ( deliveryCh ) && args ( me ) ;

178

36 37

pointcut sendSyncTimeout ( MessageExchange me , long timeoutMS , DeliveryChannel deliveryCh ) : execution ( boolean sendSync ( MessageExchange , long ) ) && target ( deliveryCh ) && args ( me , timeoutMS ) ;

38 39 40 41 42 43 44 45 46 47 48 49 50 51

/∗∗ ∗ This a b s t r a c t p o i n t c u t l e a v e s a p o s s i b i l i t y t o d e f i n e p o i n t c u t which ∗ i n t e r c e p t s not p u l l i n g t h e MessageExchange ( l i k e r e g u l a r J B I ’ s a c c e p t ∗ methods ) but pushing i t t o t h e DeliveryChannel . I t h i s s c e n a r i o sender i s ∗ pushing MessageExchange t o r e c i e v e r by invoking some method on r e c i e v e r ’ s ∗ DeliveryChannel and p a s s i n g MessageExchange as argument . ∗ ∗ DeliveryChannel ’ s implementation ∗ ∗ @param me ∗ @param deliveryCh ∗/ abstract pointcut pushAccept ( ) ;

52 53 54 55 56 57

void beforeSend ( MessageExchange me , DeliveryChannel deliveryCh , String component ) { GlassbusAgent . msgProc . processInterceptedSend ( CorrelatorsExecutor . correlate ( me , component ) , me ) ; }

58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87

void around ( MessageExchange me , DeliveryChannel deliveryCh ) throws Exception : send ( me , deliveryCh ) { try { if ( DeliveryChannelInfo . deliveryChannelMemory . containsKey ( deliveryCh . hashCode ( ) ) ) { DeliveryChannelInfo dc = DeliveryChannelInfo . deliveryChannelMemory . get ( deliveryCh . hashCode ( ) ) ; if ( dc . isStarted ) { if ( log . isDebugEnabled ( ) ) log . debug ( "Intercepting send in component: " + dc . name ) ; if ( log . isTraceEnabled ( ) ) log . trace ( "Intercepting send with:\nme: " + me + "\ndeliveryChannel: " + deliveryCh ) ; beforeSend ( me , deliveryCh , dc . name ) ; } else { if ( log . isWarnEnabled ( ) ) log . warn ( "Intercepting send in stopped component: " + dc . name ) ; } } else { if ( log . isTraceEnabled ( ) ) log . trace ( "Intercepting send with unknown DeliveryChannel: " + deliveryCh ) ; } proceed ( me , deliveryCh ) ; } catch ( MessagingException e ) { if ( log . isDebugEnabled ( ) ) log . debug ( "MessagingException in send" , e ) ;

179 // p r o c e s s E xc ep tio n throw e ; } catch ( Exception e ) { log . fatal ( "Exception while intercepting send MessageExchange" , e ) ; throw e ; } return ;

88 89 90 91 92 93 94

} ...

95 96 97 98 99

}

Listing A.5: Skeleton of GlassBus Agent Topology Component interceptor 1

public aspect JBITopologyComponentInterceptor {

2 3 4

private static Map componentToDCMap = Collections . synchronizedMap ( new HashMap ( 1 0 0 0 ) ) ;

5 6 7

private static final Log log = LogFactory . getLog ( JBITopologyComponentInterceptor . class ) ;

8 9

pointcut componentInit ( ComponentLifeCycle clc , ComponentContext cc ) : call ( void init ( ComponentContext ) ) && args ( cc ) && target ( clc ) ;

10 11

pointcut componentShutDown ( ComponentLifeCycle clc ) : call ( void shutdown ( ) ) && target ( clc ) ;

12 13

pointcut componentStart ( ComponentLifeCycle clc ) : call ( void start ( ) ) && target ( clc ) ;

14 15

pointcut componentStop ( ComponentLifeCycle clc ) : call ( void stop ( ) ) && target ( clc ) ;

16 17

private static Object glassbusAgentStartMutex = new Object ( ) ;

18 19

private static boolean glassbusAgentStarted = false ;

20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

after ( ComponentLifeCycle clc , ComponentContext cc ) : componentInit ( clc , cc ) { try { if ( cc ! = null ) { try { Component comp = ( Component ) clc ; ServiceUnitManager suManager = comp . getServiceUnitManager ( ) ; } catch ( Exception e ) { log . fatal ( "GlassbusAgent: Can’t cast to Component" , e ) ; } synchronized ( glassbusAgentStartMutex ) { if ( ! glassbusAgentStarted ) { glassbusAgentStarted = true ; GlassbusAgent . startGlussbusAgent ( ) ; }

180 } DeliveryChannel dc = cc . getDeliveryChannel ( ) ; if ( log . isDebugEnabled ( ) ) { log . debug ( "componentInit: " + cc . getComponentName ( ) + " hc: "+ clc . hashCode ( ) +"\nwith DeliveryChannel: "+ cc . getDeliveryChannel ( ) . toString ( ) ) ; } if ( DeliveryChannelInfo . deliveryChannelMemory . containsKey ( dc . hashCode ( ) )) { if ( log . isWarnEnabled ( ) ) log . warn ( "componentInit: This delivery channel was already initialized. Overwriting with: "+ dc ) ; } if ( componentToDCMap . containsKey ( clc . hashCode ( ) ) ) { if ( log . isWarnEnabled ( ) ) log . warn ( "componentInit: This component was already initialized. Overwriting with: "+ clc ) ; } DeliveryChannelInfo . deliveryChannelMemory . put ( dc . hashCode ( ) , new DeliveryChannelInfo ( cc . getComponentName ( ) ) ) ; componentToDCMap . put ( clc . hashCode ( ) , dc . hashCode ( ) ) ;

35 36 37 38

39 40

41 42

43 44 45 46

47 48

49 50

} } catch ( Exception e ) { log . fatal ( "Exception while intercepting componentInit" , e ) ; throw new RuntimeException ( e ) ; }

51 52 53 54 55

}

56

...

57 58

}

Listing A.6: Skeleton of GlassBus Agent Topology ServiceUnit and Endpoint interceptor 1

public aspect JBITopologySUInterceptor {

2 3 4

private static final Log log = LogFactory . getLog ( JBITopologySUInterceptor . class ) ;

5 6 7

pointcut suDeploy ( ServiceUnitManager suManager , String serviceUnitName , String serviceUnitRootPath ) : call ( String deploy ( String , String ) ) && args ( serviceUnitName , serviceUnitRootPath ) && target ( suManager ) ;

8 9 10

pointcut suInit ( ServiceUnitManager suManager , String serviceUnitName , String serviceUnitRootPath ) : call ( void init ( String , String ) ) && args ( serviceUnitName , serviceUnitRootPath ) && target ( suManager ) ;

11 12 13

pointcut suStart ( ServiceUnitManager suManager , String serviceUnitName ) : call ( void start ( String ) ) && args ( serviceUnitName ) && target ( suManager ) ;

14 15 16 17 18

... pointcuts for suStop , suShutDown and suUndeploy ...

181

19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

void around ( ServiceUnitManager suManager , String serviceUnitName ) throws DeploymentException : suStart ( suManager , serviceUnitName ) { try { if ( log . isDebugEnabled ( ) ) log . debug ( "GlassbusAgent: Starting SU: " + serviceUnitName ) ; String suName = ( String ) suContext . get ( ) ; if ( suName ! = null ) log . fatal ( "GlassbusAgent: Starting SU and with not empty suContext: " + suName ) ; else { if ( log . isDebugEnabled ( ) ) log . debug ( "GlassbusAgent: Setting suContext to: " + serviceUnitName ) ; suContext . set ( serviceUnitName ) ; } proceed ( suManager , serviceUnitName ) ; if ( log . isDebugEnabled ( ) ) log . debug ( "GlassbusAgent: Resetting suContext to null" ) ; suContext . set ( null ) ; } catch ( DeploymentException e ) { if ( log . isDebugEnabled ( ) ) log . debug ( "DeploymentException in suStart" , e ) ; // p r o c e s s E xc ep tio n throw e ; } catch ( Exception e ) { log . fatal ( "Exception while intercepting suStart" , e ) ; throw new RuntimeException ( e ) ; }

49 50

}

51 52

...

53 54 55

56

pointcut activateEndpoint ( ComponentContext cc , QName serviceName , String endpointName ) : call ( ServiceEndpoint activateEndpoint ( QName , String ) ) && args ( serviceName , endpointName ) && target ( cc ) ;

57 58 59 60

pointcut deactivateEndpoint ( ComponentContext cc , ServiceEndpoint endpoint ) : call ( void deactivateEndpoint ( ServiceEndpoint ) ) && args ( endpoint ) && target ( cc ) ;

61 62 63 64 65

pointcut registerExternalEndpoint ( ComponentContext cc , ServiceEndpoint externalEndpoint ) : call ( void registerExternalEndpoint ( ServiceEndpoint ) ) && args ( externalEndpoint ) && target ( cc ) ;

66 67 68 69 70

pointcut deregisterExternalEndpoint ( ComponentContext cc , ServiceEndpoint externalEndpoint ) : call ( void deregisterExternalEndpoint ( ServiceEndpoint ) ) && args ( externalEndpoint ) && target ( cc ) ;

182

71

private static ThreadLocal suContext = new ThreadLocal ( ) { protected Object initialValue ( ) { return null ; } };

72 73 74 75 76 77

before ( ComponentContext cc , QName serviceName , String endpointName ) : activateEndpoint ( cc , serviceName , endpointName ) { if ( log . isDebugEnabled ( ) ) log . debug ( "GlassbusAgent: activateEndpoint: " + cc + " : " + serviceName + " : " + endpointName ) ; String suContextValue = ( String ) suContext . get ( ) ; if ( log . isDebugEnabled ( ) ) log . debug ( "GlassbusAgent: activateEndpoint suContextValue: " + suContextValue ) ; } ...

78

79 80 81 82 83 84 85 86 87 88

}

Listing A.7: GlassBus Engine Ignitor aspect 1

package pl . edu . agh . glassbus . engine . box ;

2 3

import pl . edu . agh . glassbus . engine . GlassbusEngine ;

4 5 6

import org . apache . commons . logging . Log ; import org . apache . commons . logging . LogFactory ;

7 8 9

import javax . jbi . component . ComponentContext ; import javax . jbi . component . ComponentLifeCycle ;

10 11

public aspect GlassbusEngineIgnitor {

12 13

private static final Log log = LogFactory . getLog ( GlassbusEngineIgnitor . class ) ;

14 15

pointcut init ( ComponentLifeCycle clc , ComponentContext cc ) : call ( void init ( ComponentContext ) ) && args ( cc ) && target ( clc ) ;

16 17

private static boolean glassbusEngineHasStarted = false ;

18 19 20 21 22

23 24 25 26 27 28

after ( ComponentLifeCycle clc , ComponentContext cc ) : init ( clc , cc ) { if ( ! glassbusEngineHasStarted ) { if ( log . isInfoEnabled ( ) ) log . info ( "GlassbusEngineBox: Triggering initialization of GlassbusEngine" ) ; glassbusEngineHasStarted = true ; GlassbusEngine . startGlussbusAgent ( ) ; } else { if ( log . isDebugEnabled ( ) ) log . debug ( "GlassbusEngineBox: GlassbusEngine has already started" ) ; }

183

29

}

30 31 32

}

Listing A.8: AOP XML configuration of ServiceMix 1 2 3 4 5 6 7 8 9 10

11 12 13

14 15

16

17 18

Listing A.9: AOP XML configuration of OpenESB 1 2 3 4 5 6 7 8 9 10 11 12 13 14

15

16 17

184 Listing A.10: Sample log4j configuration of GlassBus logging system 1

2

3 4 5 6 7

8 9 10 11 12

13 14 15 16 17

18 19 20 21 22

23 24 25 26

27 28 29 30 31

Listing A.11: JMX interface of GlassBus Agent 1

public interface GlassbusAgentControlMBean {

2

public boolean isAvailable ( ) throws Exception ;

3 4

public public public public

5 6 7 8

GlobalSelectivity getGlobalSelectivityLevel ( ) ; TopologySelectivity getTopologySelectivityLevel ( ) ; void setGlobalSelectivityLevel ( GlobalSelectivity gs ) ; void setTopologySelectivityLevel ( TopologySelectivity ts ) ;

9

public AdminServiceMBean getAdminMBean ( ) ; public DeploymentServiceMBean getDeploymentMBean ( ) ; public InstallationServiceMBean getInstallationMBean ( ) ;

10 11 12 13 14

}

185 Listing A.12: Sample result of GlassBusPointStatsMBean.getEndpointStats method invoked for single endpoint with both Consumer and Provider roles 1

< a r t i f a c t i n d i v i d u a l s t a t s>

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

< a r t i f a c t s t a t s>
. . . < t o t a l s e n t r e p l i e s value="10"/> < t o t a l s e n t f a u l t s value="0"/> < t o t a l r e c e i v e d f a u l t s value="0"/> < f i r s t e r r o r value="TSTAMP1"/> < l a s t e r r o r value="TSTAMP2"/> < f i r s t f a u l t value="TSTAMP1"/> < l a s t f a u l t value="TSTAMP2"/>

33 34 35 36

Bibliography

[1] Enterprise Service Bus - Wikipedia, the free encyclopedia. URL: http://en.wikipedia.org/wiki/Enterprise service bus [2] JSR 208: Java Business Integration (JBI). URL: http://jcp.org/en/jsr/detail?id=208 [3] The Java Community Process(SM) Program. URL: http://jcp.org/ [4] JSR 312: Java Business Integration 2.0 (JBI 2.0). URL: http://jcp.org/en/jsr/detail?id=312 [5] EAI Enterprise Application Integration Solutions From iWay Software. URL: http://www.iwaysoftware.com/eai-enterprise-application-integration.html [6] Enterprise application integration - Wikipedia, the free Encyclopedia. URL: http://en.wikipedia.org/wiki/Enterprise application integration [7] Enterprise Application Integration by METAspectrum. URL: http://download.microsoft.com/download/e/3/d/e3d4d04b-fd21-44dc-8ae690e65c4fd212/marketsummary.pdf [8] Composition and Federation Patterns in Componentware Software Architectures. URL: http://www.objs.com/aits/federation.html [9] Information service patterns, Part 1: Data federation pattern. URL: http://www.ibm.com/developerworks/webservices/library/ws-soa-infoserv1/ [10] Enterprise Application - a Business Decision. URL: http://download.microsoft.com/download/e/3/d/e3d4d04b-fd21-44dc-8ae690e65c4fd212/marketsummary.pdf [11] Making the Case for ESB: Architecturally. URL: http://davidpallmann.spaces.live.com/blog/cns!E95EF9DC3FDB978E!219.entry [12] Big ball of mud - Wikipedia, the free Encyclopedia. URL: http://en.wikipedia.org/wiki/Big ball of mud [13] Integration Topologies. URL: http://msdn.microsoft.com/en-us/library/ms978718.aspx [14] Spoke-hub distribution paradigm - Wikipedia, the free Encyclopedia. URL: http://en.wikipedia.org/wiki/Hub and spoke [15] Message Broker. URL: http://msdn.microsoft.com/en-us/library/ms978579.aspx [16] Message Bus. URL: http://msdn.microsoft.com/en-us/library/ms978583.aspx

BIBLIOGRAPHY

187

[17] J2EE Management. URL: http://jcp.org/en/jsr/detail?id=77 [18] Java Management Extensions (JMX). URL: http://jcp.org/aboutJava/communityprocess/final/jsr003/index3.html [19] Java Management Extensions (JMX) Remote API. URL: http://jcp.org/en/jsr/detail?id=160 [20] Dot Language by Graphviz.org. URL: http://www.graphviz.org/doc/info/lang.html [21] Spagic SOA Enterprise Integration Platform. URL: http://spagic.org/ [22] OpenESB Sierra monitoring framework. URL: http://wiki.open-esb.java.net/Wiki.jsp?page=SierraUpdateRuntimeMonitoring http://wiki.open-esb.java.net/Wiki.jsp?page=SierraStatisticsPresentation http://wiki.open-esb.java.net/Wiki.jsp?page=SierraMBeanNotifications [23] ServiceMix Clustering. URL: http://servicemix.apache.org/clustering.html [24] Glassfish Open Source Application Server. URL: https://glassfish.dev.java.net/ [25] OpenESB HTTP binding component clustering support. URL: http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCClusteringSupport [26] OpenESB BPEL service engine clustering support. URL: http://wiki.open-esb.java.net/Wiki.jsp?page=ClusteringSupport [27] Open Group consortium. URL: http://www.opengroup.org/ [28] Message Oriented Middleware — Wikipedia, The Free Encyclopedia. URL: http://en.wikipedia.org/wiki/Message Oriented Middleware [29] Exinda Networks Application Response Measurement commercial implementation. URL: http://www.exinda.com/public/products/technology/arm.htm [30] Oracle Siebel Application Response Measurement commercial implementation. URL: http://www.oracle.com/applications/crm/siebel/crm-technology/application-responsemanagement.html [31] IBM Tivoli’s WebSphere Application Response Measurement commercial implementation. URL: http://www.forrester.com/Research/LegacyIT/Excerpt/0,7208,27997,00.html [32] Open Source Initiative (OSI). URL: http://www.opensource.org/ [33] OpenARM — Open source Application Response Measurement implementation. URL: http://open-arm.sourceforge.net/ [34] Motivation for OpenARM creation. URL: http://open-arm.sourceforge.net/why.html [35] Gartner Incorporated. URL: http://www.gartner.com/ [36] Business Process Management Initiative (BPMI). URL: http://www.bpmi.org/ [37] Complex Event Processing (CEP). URL: http://complexevents.com [38] PolePosition open source database benchmark. URL: http://www.polepos.org/

BIBLIOGRAPHY

188

[39] David Coldrick’s Weblog: Thomas Mueller and Francois Orsini discussion about H2 and Derby. January 2007. URL: http://blogs.sun.com/coldrick/entry/new version of h2 database [40] JSR 220: Enterprise JavaBeansTM 3.0. URL: http://jcp.org/en/jsr/detail?id=220 [41] Spring Framework documentation. URL: http://www.springframework.org/documentation [42] Lingo - lightweight POJO based remoting and messaging library. URL: http://lingo.codehaus.org/Home [43] Maven - Project management and comprehension tool. URL: http://maven.apache.org/ [44] Service Component Architecture Specifications. URL: http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications [45] Apache activemq – amq message store. URL: http://activemq.apache.org/amq-message-store.html [46] Apache activemq – index. URL: http://activemq.apache.org/index.html [47] Apache activemq – jca container. URL: http://activemq.apache.org/jca-container.html [48] Apache activemq – security. URL: http://activemq.apache.org/security.html [49] Apache activemq – should i use transactions. URL: http://activemq.apache.org/should-i-use-transactions.html [50] Apache activemq – should i use xa transactions. URL: http://activemq.apache.org/should-i-use-xa.html [51] Apache servicemix, the agile open source esb – 5. jbi. URL: http://servicemix.apache.org/5-jbi.html [52] Apacheode – jacob. URL: http://ode.apache.org/jacob.html [53] Best practice - wikipedia, the free encyclopedia. URL: http://en.wikipedia.org/wiki/Best practice [54] Building hierarchical structures from flat data. URL: http://www.cafeconleche.org/books/xmljava/chapters/ch04s05.html [55] Craig walls: Message-driven pojos. URL: http://www.theserverside.com/news/thread.tss?thread id=35345 [56] Esb-oriented architecture: The wrong approach to adopting soa. URL: http://www.ibm.com/developerworks/webservices/library/ws-soa-esbarch/ [57] Exploring the enterprise service bus, part 1: Discover how an esb can help you meet the requirements for your soa solution. URL: http://www.ibm.com/developerworks/webservices/library/aresbpat1/index.html?S TACT=105AGX04&S CMP=ART [58] Functional requirements - wikipedia, the free encyclopedia. URL: http://en.wikipedia.org/wiki/Functional requirements

[59] Ibm help. URL: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/inf [60] The java community process(sm) program - jsrs: Java specification requests - detail jsr914. URL: http://jcp.org/en/jsr/detail?id=914

BIBLIOGRAPHY

189

[61] Jbosswiki : Jbossmdb. URL: http://wiki.jboss.org/wiki/JBossMDB [62] Jdots - java dynamic object tree system. URL: http://www.xs4all.nl/ weertj/jdots/ [63] Jencks - message driven pojos. URL: http://jencks.org/Message+Driven+POJOs [64] Karl e. wiegers, software requirements: Practical techniques for gathering and managing requirements throughout the product development cycle, second edition, microsoft press 2003. [65] Message exchange protocols for web services. URL: http://www.w3.org/2001/03/WSWS-popa/paper39 [66] Non-functional requirements - wikipedia, the free encyclopedia. URL: http://en.wikipedia.org/wiki/Non-functional requirements [67] Not invented here - wikipedia, the free encyclopedia. URL: http://en.wikipedia.org/wiki/Not Invented Here [68] Oasis reference model for service oriented architecture 1.0. URL: http://www.oasis-open.org/committees/tc home.php?wg abbrev=soa-rm [69] Rich client platform (rcp) - why? URL: http://blogs.kiyut.com/tonny/2007/11/21/rich-client-platform-rcp-why/ [70] Service oriented architecture - wikipedia, the free encyclopedia. URL: http://en.wikipedia.org/wiki/Service-oriented architecture [71] Service oriented architecture: Inventory of distributed computing concepts. URL: http://www.informit.com/articles/article.aspx?p=349749&seqNum=1 [72] Trees in sql - joe celko. URL: http://www.ibase.ru/devinfo/DBMSTrees/sqltrees.html [73] Use jbi components for integration - java world. URL: http://www.javaworld.com/javaworld/jw-07-2006/jw-0717-jbi.html?page=2 [74] Using hierarchical data sets with aspire and tomcat. URL: http://www.onjava.com/pub/a/onjava/2003/03/05/hds.html?page=1 [75] Young, ralph r. effective requirements practices. boston: Addison-wesley, 2001. [76] 1997. Java AWT: Delegation Event Model. URL: http://java.sun.com/j2se/1.3/docs/guide/awt/designspec/events.html [77] December 2004. Application Response Measurement (ARM) Issue 4.0 V2 - Java Binding. URL: http://www.opengroup.org/tech/management/arm/doc.tpl?CALLER=index.tpl&gdid=6382 [78] June 2007. Application Response Measurement (ARM) Issue 4.1 V1 - Java Binding. URL: http://www.opengroup.org/arm/doc.tpl?CALLER=index.tpl&gdid=13747 [79] M. Corporation. Microsoft on the enterprise service bus (esb). URL: http://technet.microsoft.com/en-us/library/aa475433.aspx [80] X. Corporation and I. Palo Alto Research Center. The aspectj programming guide, 2003. URL: http://www.eclipse.org/aspectj/doc/released/progguide/index.html [81] T. Davenport. Process innovation: Reengineering work through information technology. 1993. [82] K. K. M. B. Dennis Smith, Liam O’brien, 2002. Enterprise Integration. URL: http://www.sei.cmu.edu/news-at-sei/columns/the architect/2002/4q02/architect-4q02.htm [83] R. J. J. M. V. Erich Gamma, Richard Helm. Design Patterns: Elements of Reusable Object-Oriented Software. [84] Gartner, 2000-2001. Enterprise Applications: Adoption of E-Business and Document Technologies. URL: http://findarticles.com/p/articles/mi qa3937/is 200203/ai n9019202

BIBLIOGRAPHY

190

[85] M. Gilpin. The federated future of the esb - by forrester, april 2008. URL: http://www.forrester.com/rb/download?t=1&&c=nch&o=2206&ft=1 [86] C. Glc. 1997. Supporting the log4j RepositorySelector in Servlet Containers. [87] I. Guillaume Nodet, Principal Engineer, 2007. Presentation: ServiceMix 4.0, the next generation ESB. URL: http://jaoo.dk/aarhus2007/presentation/ServiceMix+4.0,+the+next+generation+ESB [88] G. Hohpe and B. Woolf. Enterprise integration patterns. URL: http://www.eaipatterns.com/MessageRoutingIntro.html [89] A. Karazniewicz, 2008. Discussion: Which open source ESB EAI BPM messaging products do you recomend? URL: http://www.linkedin.com/answers/technology/information-technology/computerssoftware/TCH ITS CMP/214314-1882799?browseCategory=TCH SFT [90] A. M. C. M. C. L. J.-M. L. Kiczales, Gregor; John Lamping and J. Irwin. Aspect-oriented programming. 1997. Proceedings of the European Conference on Object-Oriented Programming, vol.1241, pp.220242. [91] H. Kochar. Business activity monitoring and business intelligence, 2005. URL: http://www.ebizq.net/topics/bam/features/6596.html [92] H. P. Luhn. A business intelligence system, 1958. URL: http://www.research.ibm.com/journal/rd/024/ibmrd0204H.pdf [93] D. W. McCoy. Business activity monitoring: Calm before the storm, 2002. URL: http://www.gartner.com/resources/105500/105562/105562.pdf [94] T. Mueller. H2 database engine performance tests. URL: http://www.h2database.com/html/performance.html [95] A. Polozoff. Proactive application monitoring, 2003. URL: http://www.ibm.com/developerworks/websphere/library/techarticles/0304 polozoff/polozoff.html [96] D. Power. A brief history of decision support systems, 2007, month = March, URL =. version 4.0. [97] e. b. D. B. Slack et al. Understanding business: Processes technology. 2002. [98] D. K. Taft, May 2007. Can JBI 2 Succeed Where JBI 1 Did Not? URL: http://www.eweek.com/c/a/Application-Development/Can-JBI-2-Succeed-Where-JBI-1-DidNot/ [99] P. Walker, 2007. JBI 2.0 Directions and thoughts. URL: http://www.chainforge.net/jbiresources/JAZOON07-JBI2.pdf [100] M. Welsh. Seda: An architecture for highly concurrent server applications. May. [101] Wikipedia. Application response measurement — Wikipedia, The Free Encyclopedia, 2008. [Accessed 28/05/2008]. URL: http://en.wikipedia.org/wiki/Application Response Measurement [102] Wikipedia. Binary large object — Wikipedia, The Free Encyclopedia, 2008. [Accessed 21/07/2008]. URL: http://en.wikipedia.org/wiki/Binary large object [103] Wikipedia. Business activity monitoring — Wikipedia, The Free Encyclopedia, 2008. [Accessed 09/07/2008]. URL: http://en.wikipedia.org/wiki/Business Activity Monitoring [104] Wikipedia. Business process management — Wikipedia, The Free Encyclopedia, 2008. [Accessed 09/07/2008]. URL: http://en.wikipedia.org/wiki/Business Process Management [105] Wikipedia. Complex event processing — Wikipedia, The Free Encyclopedia, 2008. 12/07/2008]. URL: http://en.wikipedia.org/wiki/Complex Event Processing

[Accessed

[106] Wikipedia. Proof of concept — Wikipedia, The Free Encyclopedia, 2008. [Accessed 21/08/2008]. URL: http://en.wikipedia.org/wiki/Proof of concept

BIBLIOGRAPHY

191

[107] Wikipedia. System monitor — Wikipedia, The Free Encyclopedia, 2008. [Accessed 07/07/2008]. URL: http://en.wikipedia.org/wiki/System monitor [108] M. Wright. The role of the enterprise service bus (infoq - video presentation). URL: http://www.infoq.com/presentations/Enterprise-Service-Bus [109] I. Xerox Corporation, Palo Alto Research Center and Contributors. The aspectj development environment guide, 2005. URL: http://www.eclipse.org/aspectj/doc/released/devguide/index.html

AOP-Based Monitoring Instrumentation of JBI-Compliant ESB

ESB International

ESB template

Final Programme - ESB 2014

ESB Contactor.pdf - Google Drive

Introduction to ESB and Petals ESB - CCSL - USP

Building ESB Product Lines

ESB template

Fiorano ESB Value Proposition

HOUSE BILL REPORT ESB 6617

yucesoy & ates ESB 2017

JBoss ESB Sniffer - IEEE Xplore

Kafka Streaming Brokers/ESB

JBoss ESB Sniffer - IEEE Xplore

ESB - Modern SOA Infrastructure - CiteSeerX

Distribution Contracted Wind - ESB Networks

ESB template - European Society of Biomechanics

ESB template - European Society of Biomechanics

ESB template - European Society of Biomechanics

SOA using Open ESB, BPEL, and NetBeans (2007) - Huihoo

BAM Dashboards for Open ESB and Java CAPS

ESB template - European Society of Biomechanics

BPEL and ESB - James Smith's Blogs

Crochet garde-neige Euro ESB - sbo3.de

Universal architecture of monitoring ESB compliant with ... - Open ESB

Universal architecture of monitoring ESB compliant with ... - Open ESB

Suggest Documents