A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems Naeem Esfahani Sam Malek João P. Sousa Hassan Gomaa Daniel A. Menascé 12th International Conference on Model Driven Engineering Languages and Systems Department of computer science Fairfax, Virginia, USA
Overview Usable by domain-expert Specify requirements Build SOA systems Sufficient semantics Generate executable architecture 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 2
Outline Motivation SASSY Framework Activity-Oriented Language Overview Structural properties Behavioral properties Architecture Generation Conclusion 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 3
Situated Software Systems Situated software systems Smart spaces, wirelessly connected sensors, highly mobile platforms, and so on Primary role of the system is not known at design-time Smart emergency response system Smart buildings with sensors Smart fire stations that monitor the sensors and dispatch fire engines Smart fire engines wirelessly connected to the rest of the system Smart hospitals monitoring the situation and when necessary dispatch smart ambulances The role of the system may change Traffic accident, hurricane, etc. 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 4
Key Characteristics Rapid run-time composition by end-user Role of the system is not completely known at design-time Dynamic and unpredictable New Breed of Systems Requirements may change at run-time Autonomous entities expected to integrate and operate at run-time QoS requirements are the key drivers 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 5
What is needed? Different way of composing software systems Minimize human reasoning and manual intervention Rapid composition Automatic From requirements Autonomous reconfiguration at run-time QoS requirements (Adaptation) User s changing need (Evolution) 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 6
State of the Art Commonly agreed that reasoning about adaptation choices requires a proper model of the system Architecture as the primary focus of reasoning Proper level of granularity Self-Adaptive Software Automatic change of functionality at run-time E.g., Darwin from Imperial, ArchStudio from UCI, Rainbow from CMU, etc. Underlying assumption The primary functionality of system is known at design-time An architectural model of the system is available What about the situations where the role of the system changes at run-time? 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 7
Outline Motivation SASSY Framework Activity-Oriented Language Overview Structural properties Behavioral properties Architecture Generation Conclusion 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 8
SASSY: Self-Architecting Software SYstems Pushing the envelope Self-adaptive software f self-architecting software User specifies the functional and QoS requirements An activity-oriented modeling language Vision Construct an architectural model and the corresponding software system automatically Satisfy the user s need (functional) Near optimal (QoS) Underlying assumptions (standards, abstraction) Service orientation (standards, loose coupling, ) Domain ontology (well-defined terms and concepts) 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 9
SASSY Concepts Service Activity Schemas (SAS) An activity oriented language Used to model domain-expert s requirements Service Sequence Scenarios (SSS) A construct in SAS Used to specify QoS requirements Architecture Executable model of the system Generated from the SAS Augmented with the services 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 10
SASSY s Overall Process Monitoring data Service Activity Schema Base Architecture Alternative Architecture 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 11
Outline Motivation SASSY Framework Activity-Oriented Language Overview Structural properties Behavioral properties Architecture Generation Conclusion 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 12
Language Requirements Usable by domain-expert Support long-living activities Abstraction for physical entities that may be initiated/engaged at any point in time E.g., sensors and actuators Treat QoS requirements as first class constructs Used for adaptation Precisely defined Be able to generate executable system UML Mainly intended for software engineers Lacks native support for modeling QoS requirements Semantic BPEL Too low-level to be used by domain-expert No support for modeling QoS requirements Lacks sufficient support for modeling long-living activities BPMN Not formally defined Not intended for execution No support for modeling QoS requirements Lacks sufficient support for modeling long-living activities 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 13
An Example of SAS 911 Dispatcher 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 14
An Example of SAS 911 Dispatcher QoS Requirements QoS Dimension: Availability Goal Value: 99% 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 15
An Example of SAS High Level Composition 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 16
Outline Motivation SASSY Framework Activity-Oriented Language Overview Structural properties Behavioral properties Architecture Generation Conclusion 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 17
Meta-modeling Structure of the language Domain Specific Modeling Language Generic Modeling Environment 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 18
Meta-Model Model Atom Connection Reference Set FCO 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 19
Overview of the Meta-Model Flow Defines the constructs in the SAS How they are interconnected by flow 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 20
Overview of the Meta-Model Services Defines the role of service placeholders in SAS Subset of SAS which is used to model inside of the service 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 21
Overview of the Meta-Model QoS Defines the QoS dimensions and some examples How they are related to the SSS 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 22
Outline Motivation SASSY Framework Activity-Oriented Language Overview Structural properties Behavioral properties Architecture Generation Conclusion 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 23
Z Specification Definition and Axioms Use Z Abstracts away from the implementation details Formal enough to precisely specify the behavior [Node,Token] Type ::= In Out Start End ExclusiveGW InclusiveGW ParallelGW Activity LoopingActivity ÆInput: Node x P Token f P Token ÆLoop: Node x P Token f P Token ÆMerge: Node x P Token f P Token ÆGenerate: Node x P Token f P Token ÆAll: Node x P Token f P Token ÆPossible: Node x P Token f P Token ÆOnePoss: Node x P Token f P Token Given operations Consume input(s) Produce result(s) Replicate output(s) 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 24
Z Specification an Example»SAS ÆTokens : P Token»SASInit ÆSAS' «ÆTokens' = 0»ActivityNode ÆDSAS; n?: Node; t?: Type; i: P Token «Æt? = Activity i = Input(n?,Tokens) ÆTokens' = (Tokens U Possible(n?,Generate(n?,i))) \ i 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 25
Outline Motivation SASSY Framework Activity-Oriented Language Overview Structural properties Behavioral properties Architecture Generation Conclusion 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 26
Architecture Generation Using GReAT Refers to Refers to SAS Meta-model Transformation Modeling Model Transformation Specification in GReAT Architecture Meta-model Transformation Execution Input SAS to Architecture Model Transformer GReAT Engine Transforms SAS Model Architecture Model 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 27
Outline Motivation SASSY Framework Activity-Oriented Language Overview Structural properties Behavioral properties Architecture Generation Conclusion 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 28
Ongoing Work Optimal architecture selection (WOSP/SIPEW 2010) Modeling transactions Modeling faults Verifying composition by LTSA Adaptation and evolution infrastructure Developing a repository of QoS patterns Automated application 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 29
Conclusion An activity-oriented language Usable by domain expert Allows modeling functional and QoS requirements Sufficient semantics to generate executable architectural models automatically The centerpiece of Self-Architecting Software SYstems (SASSY) Supported by 10/08/2009 A Modeling Language for Activity-Oriented Composition of Service-Oriented Software Systems 30