SASSY is a framework that allows software systems to self-architect and adapt to changes in their computing environment or requirements. It uses models called Service Activity Schemas (SAS) to specify system requirements and generate an initial architecture. SASSY then monitors quality of service metrics and dynamically changes the architecture by applying patterns if the overall utility falls, in order to maintain the best QoS. It transforms SAS models into executable architectures and facilitates simulation and testing through model transformations and existing tools.

1. SASSY: A Framework for Self-
Architecting Service-Oriented
Systems

2. the main parts of the paper
Over view
The Challenge of Self-Architecting
The SASSY Approach
Service Activity Schemas
Generating the Base Architecture
Self-Architecting
Self Adaptation
The SASSY Development Environment

3. Overview
• The idea is to provide a way in the distributed system to monitor the
computing environment and change it is behavior and requirement in
order to make the system friendly with computing environment and to get
the best of quality of service.
• This quality can be determined by the services that provide to customer
and how such services are helpful for their business.
• Make change to the system with the change in the computing
environment by dynamically monitoring the computing environment.
• SASSY (Self-architecting Software Systems) is framework in which the
system requirement may change.
• We can imagine SASSY as many service providers are available to provide
services at different quality of service level and different cost.
Chapter 1

4. The Challenge of Self-
Architecting
• Changing the software system architecture to obtain the
best QoS is complex; because some times to get the best
quality it requires some change that may affect the quality
and the performance of other services.
For example from paper:
• Replication to improve the system reliability create the
system that is more reliable but also costly to deploy and
operate.
 So we have to take care about stakeholder priority in
system architecture change.
Chapter 2

5. The Challenge of Self-Architecting
• The difficulty of determine and coordinate
1) The requirement can be define by using a visual activity-modeling
language which is used by SASSY to determine which service are part of
the system and which is are not and how to coordinate those service
with system.
2) The difficulty of determines the original system architecture and how
can the system automatically change it is architecture with the current
system environment to obtain the best QoS.
3) It is NP-hard optimization problem.
• To overcome these challenges SASSY generate near optimal architecture
and services to deal with these complexity

6. The SASSY ApproachChapter 3

7.  Software engineering
 We have 3 type of software engineering:
1) Services developers : who responsible to develop services and register
them in service registry by which the ASSYS can search and find such
services
2) Architectures developers: whose responsible to develop QoS architecture
pattern such as:
 Replication for fault tolerance
 load balancing for increased throughput
 mediation for secure communication
software performance engineer use those pattern to define the QoS and
determine how such pattern effect the performance.
3) Architectures developers: who develop software adaptations
pattern, which is used to dynamically exchange the current execution
architecture to another architecture according to the execution
environment

8. • Domain experts
• Specify SAS (service activity schemas) and SSA
which express system requirement those
requirements are used by SASSY to
automatically generate a base system service
architectures, then select the optimal
architecture by playing the QoS pattern that
help to maximize system utility.

9. MAPE-K
(Monitor, analyze, plan, execute, knowl
edge) Loop
SASSY runtime self re architecting

10. (Monitor, analyze, plan, execute, knowl
edge) Loop
1) SASSY monitoring the current running system
component and generate QoS values.
2) The metric QoS values are then pass to the
analyzer in order to compute the system utility
3) If the utility is fall the system send a request to
the architecture planer to determine the near-
optimal architecture.
4) The self-adaptation component executes the
changes to the running system through the
adaptation patterns.

11. Service Activity Schemas
• SAS is a visual requirements specification
language using (Business Process Modeling
Notation BPMN)
Chapter 4
The modeling constructs in SAS
• service sequence scenarios (SSSs)

12. 1) The first step in generating an SAS model is to select the
required service and activities from the domain ontology.
SAS deferent the local activates from service; that is
activates perform from external entities.
2) The domain expert specifies the sequence of interactions
among service and activities.
3) Step (2) done by the help of gateways that manage the
flow of events.
4) The domain expert specifies the QoS requirement through
service sequence scenarios (SSSs) is a well-formed sub
graph of SAS it use to manage complexity and ensure
autonomy

13. Gateway example

14. SAS for monitoring fire emergencies in public buildings
As we see the fire emergencies system contains: smoke detectors and fire sprinklers.
This SAS contains three services and a composite activity:
1. Building locator
2. Occupancy awareness
3. Building category finder
The start event (SomkeDet) starts two parallel threads of control:
1. Emergency phone system tries to contact the building renter.
 If the system makes contact with the renter, it forwards the phone call to an operator
otherwise it sends an investigate event to the police station.
2. External building locator service finds the incident physical address. Produce tow external
services:
 renter awareness (determine the number of renter in the building)
 building category finder (determine the building type)
The system then uses this information to request appropriate assistance.

15. Generating the Base
Architecture
• The SSA provide structural and behavioral
models for SASSY.
• The SSA is an up-to-date representation of the
running software system.
• The SSA structural models are based on xADL
(eXtensible Architectural Description
Language)
Chapter 5

17. • To generate the base architecture from an SAS
model, we used a model driven engineering (MDE)
1) We developed a model to model transformer to
generate SSA models from SAS models.
2) Services in SAS are transformed to the components
and connectors to form the SSA structural model in
xADL.
3) The SAS sequence of activities and services are
transformed to a coordinator component.
4) SAS has a formal semantics so SAS models can be
checked for syntactic correctness and consistency.
5) SASSY can validate behavioral characteristics, such as
deadlocks.

18. Self-Architecting
Software architectural patterns define templates
that can be reused to solve the problem of
automated generation of architectures.
 This pattern contains one or more
components that can be linked by connectors.
 Each component can be associated with one
or more service types, which are provided by
one or more service providers.
 Also includes one or more QoS metrics
Chapter 6

19. We have different attributes such as:
Response time.
 Availability.
Security.
Which affect the utility functions of QoS.
SASSY combines a utility function into a single global utility function.
SASSY monitors the utility values for the running system and make
self-adaptation if one of the utility values is fall.
QoS metrics

20. Self Adaptation
A software adaptation descript the steps needed to
dynamically adapt a system at runtime from one
configuration to another without effect its
functionality.
An adaptation pattern can be as a state machine
that defines the sequence of states services that
transmit from an active to a silent state.
A service is active: when it runs in its normal
operation.
A service is silent: when the clients no longer
communicate with it.
Chapter 7

21. The SASSY Development
Environment
Chapter 8
The main result was developed the model transformation and
optimization capabilities as GME plug-ins that can read and manipulate
GME models. We use the XTEAM to execute the architecture model
with actual service.
We create automated generation architecture for SAS model to do it is
functionality without any problem and correctly also we make sure
about the QoS to obtain the best quality for SOA, and we show how to
use the existed tools that help us to simulate and testing our models.