An Extensible Architecture for Run-time Monitoring of Conversational - - PowerPoint PPT Presentation

an extensible architecture for run time monitoring of
SMART_READER_LITE
LIVE PREVIEW

An Extensible Architecture for Run-time Monitoring of Conversational - - PowerPoint PPT Presentation

An Extensible Architecture for Run-time Monitoring of Conversational Web Services Konstantinos Bratanis, Dimitris Dranidis, Anthony J.H. Simons South East European Research Centre (SEERC) Research Centre of the University of Sheffield and CITY


slide-1
SLIDE 1

An Extensible Architecture for Run-time Monitoring of Conversational Web Services

Konstantinos Bratanis, Dimitris Dranidis, Anthony J.H. Simons

South East European Research Centre (SEERC) Research Centre of the University of Sheffield and CITY College Thessaloniki, Greece kobratanis@seerc.org, dranidis@city.academic.gr Department of Computer Science University of Sheffield Regent Court, 211 Portobello Street, Sheffield S1 4DP, UK a.simons@dcs.shef.ac.uk

MONA+ 2010 - Cyprus - December 1, 2010

slide-2
SLIDE 2

Motivation Monitoring Architecture Evaluation Conclusions

Outline

1

Motivation

2

Monitoring Architecture

3

Evaluation

4

Conclusions

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-3
SLIDE 3

Motivation Monitoring Architecture Evaluation Conclusions

Outline

1

Motivation

2

Monitoring Architecture

3

Evaluation

4

Conclusions

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-4
SLIDE 4

Motivation Monitoring Architecture Evaluation Conclusions

Outline

1

Motivation

2

Monitoring Architecture

3

Evaluation

4

Conclusions

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-5
SLIDE 5

Motivation Monitoring Architecture Evaluation Conclusions

Outline

1

Motivation

2

Monitoring Architecture

3

Evaluation

4

Conclusions

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-6
SLIDE 6

Motivation Monitoring Architecture Evaluation Conclusions

Monitoring Conversation Web Services

Even if a Web service was fault-free during testing, it could deviate during run-time, since its context of execution is subject to continuous change. A service provider could modify a Web service without prior notifying all consumers, or a Web service could be substituted within a composite Web service. Monitoring is the primary trigger for adaptation in service-based applications. Conversational Web services introduce added complexity when it comes to monitoring (conversational protocol / state per consumer).

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-7
SLIDE 7

Motivation Monitoring Architecture Evaluation Conclusions

Monitoring Conversation Web Services

Even if a Web service was fault-free during testing, it could deviate during run-time, since its context of execution is subject to continuous change. A service provider could modify a Web service without prior notifying all consumers, or a Web service could be substituted within a composite Web service. Monitoring is the primary trigger for adaptation in service-based applications. Conversational Web services introduce added complexity when it comes to monitoring (conversational protocol / state per consumer).

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-8
SLIDE 8

Motivation Monitoring Architecture Evaluation Conclusions

Monitoring Conversation Web Services

Even if a Web service was fault-free during testing, it could deviate during run-time, since its context of execution is subject to continuous change. A service provider could modify a Web service without prior notifying all consumers, or a Web service could be substituted within a composite Web service. Monitoring is the primary trigger for adaptation in service-based applications. Conversational Web services introduce added complexity when it comes to monitoring (conversational protocol / state per consumer).

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-9
SLIDE 9

Motivation Monitoring Architecture Evaluation Conclusions

Monitoring Conversation Web Services

Even if a Web service was fault-free during testing, it could deviate during run-time, since its context of execution is subject to continuous change. A service provider could modify a Web service without prior notifying all consumers, or a Web service could be substituted within a composite Web service. Monitoring is the primary trigger for adaptation in service-based applications. Conversational Web services introduce added complexity when it comes to monitoring (conversational protocol / state per consumer).

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-10
SLIDE 10

Motivation Monitoring Architecture Evaluation Conclusions

Motivation for an Extensible Monitoring Architecture

Cross-layer adaptation requires different monitors at different layers to trigger adaptation. Correlation of cross-layer monitors could facilitate more efficient and effective adaptation. Numerous approaches for monitoring Web services exist in literature and they focus on a particular layer.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-11
SLIDE 11

Motivation Monitoring Architecture Evaluation Conclusions

Motivation for an Extensible Monitoring Architecture

Cross-layer adaptation requires different monitors at different layers to trigger adaptation. Correlation of cross-layer monitors could facilitate more efficient and effective adaptation. Numerous approaches for monitoring Web services exist in literature and they focus on a particular layer.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-12
SLIDE 12

Motivation Monitoring Architecture Evaluation Conclusions

Motivation for an Extensible Monitoring Architecture

Cross-layer adaptation requires different monitors at different layers to trigger adaptation. Correlation of cross-layer monitors could facilitate more efficient and effective adaptation. Numerous approaches for monitoring Web services exist in literature and they focus on a particular layer.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-13
SLIDE 13

Motivation Monitoring Architecture Evaluation Conclusions

Logical Classification of Monitors

We have identified two approaches for constructing monitors:

1

Heavy-weight monitor: A single monitor supports the monitoring of different aspects of a Web service.

2

Light-weight monitor: A single monitor supports the monitoring of one aspect of a Web service. Several light-weight monitors can be used to monitor diversified aspects of a service.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-14
SLIDE 14

Motivation Monitoring Architecture Evaluation Conclusions

Logical Classification of Monitors

We have identified two approaches for constructing monitors:

1

Heavy-weight monitor: A single monitor supports the monitoring of different aspects of a Web service.

2

Light-weight monitor: A single monitor supports the monitoring of one aspect of a Web service. Several light-weight monitors can be used to monitor diversified aspects of a service.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-15
SLIDE 15

Motivation Monitoring Architecture Evaluation Conclusions

Logical Classification of Monitors

We have identified two approaches for constructing monitors:

1

Heavy-weight monitor: A single monitor supports the monitoring of different aspects of a Web service.

2

Light-weight monitor: A single monitor supports the monitoring of one aspect of a Web service. Several light-weight monitors can be used to monitor diversified aspects of a service.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-16
SLIDE 16

Motivation Monitoring Architecture Evaluation Conclusions

Monitoring Scalability

We have identified two approaches for scaling monitoring capabilities:

1

A single service acting as a message gateway for forwarding all requests/responses of the monitored services to specific monitors, which can be added and removed at run-time.

2

A pool of different individual monitor services that are being attached to the monitored services at run-time.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-17
SLIDE 17

Motivation Monitoring Architecture Evaluation Conclusions

Monitoring Scalability

We have identified two approaches for scaling monitoring capabilities:

1

A single service acting as a message gateway for forwarding all requests/responses of the monitored services to specific monitors, which can be added and removed at run-time.

2

A pool of different individual monitor services that are being attached to the monitored services at run-time.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-18
SLIDE 18

Motivation Monitoring Architecture Evaluation Conclusions

Monitoring Scalability

We have identified two approaches for scaling monitoring capabilities:

1

A single service acting as a message gateway for forwarding all requests/responses of the monitored services to specific monitors, which can be added and removed at run-time.

2

A pool of different individual monitor services that are being attached to the monitored services at run-time.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-19
SLIDE 19

Motivation Monitoring Architecture Evaluation Conclusions

Message Interception Techniques

1 Handler-Based Interception 2 Wrapper-Based Interception 3 Proxy-Based Interception Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-20
SLIDE 20

Motivation Monitoring Architecture Evaluation Conclusions

Handler-Based Interception

A handler is attached to the monitored service and/or to the consumer. The request/response messages are processed first by the handler.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-21
SLIDE 21

Motivation Monitoring Architecture Evaluation Conclusions

Wrapper-Based Interception

The monitored service is wrapped within another service. The wrapper mediates between the service and the consumer.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-22
SLIDE 22

Motivation Monitoring Architecture Evaluation Conclusions

Proxy-Based Interception

An intermediate node acts as a network proxy. It transparently intercepts the messages.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-23
SLIDE 23

Motivation Monitoring Architecture Evaluation Conclusions

Monitoring Session Handling

For each instance of the monitored Web service, a new monitoring session is created. The monitoring session is uniquely identified by a monitoring session identifier (MSID).

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-24
SLIDE 24

Motivation Monitoring Architecture Evaluation Conclusions

The Monitoring Architecture

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-25
SLIDE 25

Motivation Monitoring Architecture Evaluation Conclusions

Integration of a Behavioural Conformance Monitor

JSXM is a model-based testing tool which uses the Stream X-Machine (SXM) formalism, in order to generate test cases and animate an SXM model. The functionality of JSXM was exposed through an API and it was integrated in the architecture as a monitor. The JSXM-based monitor is able to check the behavioural conformance of a Web service using an SXM model as an

  • racle.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-26
SLIDE 26

Motivation Monitoring Architecture Evaluation Conclusions

Integration of a Behavioural Conformance Monitor

JSXM is a model-based testing tool which uses the Stream X-Machine (SXM) formalism, in order to generate test cases and animate an SXM model. The functionality of JSXM was exposed through an API and it was integrated in the architecture as a monitor. The JSXM-based monitor is able to check the behavioural conformance of a Web service using an SXM model as an

  • racle.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-27
SLIDE 27

Motivation Monitoring Architecture Evaluation Conclusions

Integration of a Behavioural Conformance Monitor

JSXM is a model-based testing tool which uses the Stream X-Machine (SXM) formalism, in order to generate test cases and animate an SXM model. The functionality of JSXM was exposed through an API and it was integrated in the architecture as a monitor. The JSXM-based monitor is able to check the behavioural conformance of a Web service using an SXM model as an

  • racle.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-28
SLIDE 28

Motivation Monitoring Architecture Evaluation Conclusions

Integration of a Behavioural Conformance Monitor

JSXM works as follows:

1

JSXM transforms the actual Web service requests and responses to SXM inputs and outputs.

2

Then, it animates the SXM model using these inputs and produces the expected SXM output.

3

Finally, if the transformed actual response does not match the expected SXM output, there is a violation in the behaviour of the monitored Web service.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-29
SLIDE 29

Motivation Monitoring Architecture Evaluation Conclusions

Integration of a Behavioural Conformance Monitor

JSXM works as follows:

1

JSXM transforms the actual Web service requests and responses to SXM inputs and outputs.

2

Then, it animates the SXM model using these inputs and produces the expected SXM output.

3

Finally, if the transformed actual response does not match the expected SXM output, there is a violation in the behaviour of the monitored Web service.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-30
SLIDE 30

Motivation Monitoring Architecture Evaluation Conclusions

Integration of a Behavioural Conformance Monitor

JSXM works as follows:

1

JSXM transforms the actual Web service requests and responses to SXM inputs and outputs.

2

Then, it animates the SXM model using these inputs and produces the expected SXM output.

3

Finally, if the transformed actual response does not match the expected SXM output, there is a violation in the behaviour of the monitored Web service.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-31
SLIDE 31

Motivation Monitoring Architecture Evaluation Conclusions

Integration of a Behavioural Conformance Monitor

JSXM works as follows:

1

JSXM transforms the actual Web service requests and responses to SXM inputs and outputs.

2

Then, it animates the SXM model using these inputs and produces the expected SXM output.

3

Finally, if the transformed actual response does not match the expected SXM output, there is a violation in the behaviour of the monitored Web service.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-32
SLIDE 32

Motivation Monitoring Architecture Evaluation Conclusions

Evaluation setup

The evaluation involved a linearly increasing number of consumers accessing concurrently a monitored service.

4 different interaction scenarios were used by the consumers.

A conversational service was deployed in JBoss AS, in order to be the service under monitoring. The monitoring framework was deployed in the same server.

Intel Core 2 Quad Q8400 4GB Ram

  • penSUSE 11.2

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-33
SLIDE 33

Motivation Monitoring Architecture Evaluation Conclusions

Evaluation setup

The evaluation involved a linearly increasing number of consumers accessing concurrently a monitored service.

4 different interaction scenarios were used by the consumers.

A conversational service was deployed in JBoss AS, in order to be the service under monitoring. The monitoring framework was deployed in the same server.

Intel Core 2 Quad Q8400 4GB Ram

  • penSUSE 11.2

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-34
SLIDE 34

Motivation Monitoring Architecture Evaluation Conclusions

Evaluation setup

The evaluation involved a linearly increasing number of consumers accessing concurrently a monitored service.

4 different interaction scenarios were used by the consumers.

A conversational service was deployed in JBoss AS, in order to be the service under monitoring. The monitoring framework was deployed in the same server.

Intel Core 2 Quad Q8400 4GB Ram

  • penSUSE 11.2

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-35
SLIDE 35

Motivation Monitoring Architecture Evaluation Conclusions

Evaluation setup

The evaluation involved a linearly increasing number of consumers accessing concurrently a monitored service.

4 different interaction scenarios were used by the consumers.

A conversational service was deployed in JBoss AS, in order to be the service under monitoring. The monitoring framework was deployed in the same server.

Intel Core 2 Quad Q8400 4GB Ram

  • penSUSE 11.2

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-36
SLIDE 36

Motivation Monitoring Architecture Evaluation Conclusions

Evaluation setup

The evaluation involved a linearly increasing number of consumers accessing concurrently a monitored service.

4 different interaction scenarios were used by the consumers.

A conversational service was deployed in JBoss AS, in order to be the service under monitoring. The monitoring framework was deployed in the same server.

Intel Core 2 Quad Q8400 4GB Ram

  • penSUSE 11.2

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-37
SLIDE 37

Motivation Monitoring Architecture Evaluation Conclusions

Evaluation setup

The evaluation involved a linearly increasing number of consumers accessing concurrently a monitored service.

4 different interaction scenarios were used by the consumers.

A conversational service was deployed in JBoss AS, in order to be the service under monitoring. The monitoring framework was deployed in the same server.

Intel Core 2 Quad Q8400 4GB Ram

  • penSUSE 11.2

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-38
SLIDE 38

Motivation Monitoring Architecture Evaluation Conclusions

Evaluation setup

The evaluation involved a linearly increasing number of consumers accessing concurrently a monitored service.

4 different interaction scenarios were used by the consumers.

A conversational service was deployed in JBoss AS, in order to be the service under monitoring. The monitoring framework was deployed in the same server.

Intel Core 2 Quad Q8400 4GB Ram

  • penSUSE 11.2

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-39
SLIDE 39

Motivation Monitoring Architecture Evaluation Conclusions

TravelAgency Web Service

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-40
SLIDE 40

Motivation Monitoring Architecture Evaluation Conclusions

Evaluation Scenarios

Interaction scenarios containing different execution sequences. Scenario Effect Execution 1 Booked Succeeds 2 Booked with car Succeeds 3 No hotel is selected Fails 4 No checkout is done Fails

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-41
SLIDE 41

Motivation Monitoring Architecture Evaluation Conclusions

Experimental Result

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-42
SLIDE 42

Motivation Monitoring Architecture Evaluation Conclusions

Future directions

Improve the implementation of the monitoring architecture to support monitoring of long-running (persistent) Web service interactions. Investigate extensions for supporting the integration of monitors for both non-functional and functional aspects of conversational as well as non-conversational Web services. Integrate existing monitoring tools from the literature to the monitoring architecture. Continue evaluating the monitoring architecture using more complex monitoring scenarios.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-43
SLIDE 43

Motivation Monitoring Architecture Evaluation Conclusions

Future directions

Improve the implementation of the monitoring architecture to support monitoring of long-running (persistent) Web service interactions. Investigate extensions for supporting the integration of monitors for both non-functional and functional aspects of conversational as well as non-conversational Web services. Integrate existing monitoring tools from the literature to the monitoring architecture. Continue evaluating the monitoring architecture using more complex monitoring scenarios.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-44
SLIDE 44

Motivation Monitoring Architecture Evaluation Conclusions

Future directions

Improve the implementation of the monitoring architecture to support monitoring of long-running (persistent) Web service interactions. Investigate extensions for supporting the integration of monitors for both non-functional and functional aspects of conversational as well as non-conversational Web services. Integrate existing monitoring tools from the literature to the monitoring architecture. Continue evaluating the monitoring architecture using more complex monitoring scenarios.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-45
SLIDE 45

Motivation Monitoring Architecture Evaluation Conclusions

Future directions

Improve the implementation of the monitoring architecture to support monitoring of long-running (persistent) Web service interactions. Investigate extensions for supporting the integration of monitors for both non-functional and functional aspects of conversational as well as non-conversational Web services. Integrate existing monitoring tools from the literature to the monitoring architecture. Continue evaluating the monitoring architecture using more complex monitoring scenarios.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-46
SLIDE 46

Motivation Monitoring Architecture Evaluation Conclusions

Conclusions

A primary objective of the implemented monitoring architecture was to provide a platform for integrating cross-layer monitoring approaches for Web services. Implementing a monitoring architecture for Web services involves issues such as message interception, session handling and concurrency. The presented monitoring architecture is agnostic to the interception mechanism used. Finally, the architecture is not bound to a specific vendor and thus it can be fully utilised within service-based applications.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-47
SLIDE 47

Motivation Monitoring Architecture Evaluation Conclusions

Conclusions

A primary objective of the implemented monitoring architecture was to provide a platform for integrating cross-layer monitoring approaches for Web services. Implementing a monitoring architecture for Web services involves issues such as message interception, session handling and concurrency. The presented monitoring architecture is agnostic to the interception mechanism used. Finally, the architecture is not bound to a specific vendor and thus it can be fully utilised within service-based applications.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-48
SLIDE 48

Motivation Monitoring Architecture Evaluation Conclusions

Conclusions

A primary objective of the implemented monitoring architecture was to provide a platform for integrating cross-layer monitoring approaches for Web services. Implementing a monitoring architecture for Web services involves issues such as message interception, session handling and concurrency. The presented monitoring architecture is agnostic to the interception mechanism used. Finally, the architecture is not bound to a specific vendor and thus it can be fully utilised within service-based applications.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-49
SLIDE 49

Motivation Monitoring Architecture Evaluation Conclusions

Conclusions

A primary objective of the implemented monitoring architecture was to provide a platform for integrating cross-layer monitoring approaches for Web services. Implementing a monitoring architecture for Web services involves issues such as message interception, session handling and concurrency. The presented monitoring architecture is agnostic to the interception mechanism used. Finally, the architecture is not bound to a specific vendor and thus it can be fully utilised within service-based applications.

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational

slide-50
SLIDE 50

Motivation Monitoring Architecture Evaluation Conclusions

Thank you for your attention! ...Questions?

Bratanis, Dranidis, Simons - SEERC/University of Sheffield An Extensible Architecture for Run-time Monitoring of Conversational