.. Overview
Quality attributes as those on Figure3.14are the overall factors that affect run-time behavior, system design, and user experience. They represent areas of concern that have the potential for application wide impact across layers and tiers. Some of these attributes are related to the overall system design, while others are specific to run time, design time, or user centric issues. In this chap-ter we look at some quality attribute issues of Weda.
Figure 3.14: QA
We will describe performance, scalability and extensibility QA’s in the next section. Other quality attributes are not a subject of Weda architectural style rather than the design of the application. Availability is the degree to which a system or component is operational and accessible when required for use.
Service providers usually agree to include each service in a SLA. Usability is a measure of the quality of a user’s experience in interacting with information or services. Security is important attribute. Message encryption can be in place to preserve privacy. The identity of the external service provider should be authenticated. For example, Websocket servers that host Weda endpoints can be configured to use Secure Sockets Layers (SSLs) and digital certificates to encrypt data transmission and authenticate the communicating parties while messages can be encrypted by other existing standards.
.. Performance
Performance is an important quality attribute that is usually affected negatively in SOAs. It is an indication of the responsiveness of a system to execute any action within a given time interval and can be measured in terms of latency or throughput. Latency is probably more interesting in most applications (higher throughput can be achieved by replication, lower latency is much more difficult to get).
Performance testing is a type of testing intended to determine the respon-siveness, throughput, reliability, and/or scalability of a system under a given workload (SUT). Although performance testing and load testing can seem sim-ilar, their goals are different. On one hand, performance testing uses load test-ing techniques and tools for measurement and benchmarktest-ing purposes and
uses various load levels. On the other hand, load testing is meant to test the system by constantly and steadily increasing the load on the system till the time it reaches the threshold limit.
Performance can be improved by optimizing caching techniques, minimiz-ing RTT (e.g. number of turns), minimizminimiz-ing request size or minimizminimiz-ing the payload. Weda architectural style has smaller payload size against the Webser-vices over HTTP because of minimal header of Websocket transport (and as we show in chapter9, this parameter have not significant participation on overal RTT). Another performance (especially for RPT) improvement is achieved by pipelining as described in chapter3.5.4. Another ways for reducing the pay-load in Weda are:
• Enable compression: websocket DEFLATE compression [90] MAY be used at transport level.
• Optimize messages: MTOM [87] encoding MAY be used at message level.
.. Scalability
Scalability is the capability of a system, a network or a process to handle grow-ing number of work in capable manner. In general, it is related to response time (how long does it take to process a request), throughput (how many re-quests overall can be processed per unit of time), or timeliness (ability to meet deadlines, i.e., to process a request in a deterministic and acceptable amount of time). There are two ways of escalating the content delivery speed in the web system, yet decreasing the transmission latency of contents being served by the server to the browser. Vertical way of increasing the performance is to increase the physical resources in the server to have more power to execute its functions. It could be done by adding more processor (RAM, disks) to the server. Typically, vertical scaling has no impact on application design and con-figuration. But horizontal scaling can be a problem if applications have server affinity as depending on sessions. And how the system is configured to manage that affinity. Horizontal way of increasing performance is to create a new sys-tem which is more efficient and scalable. For example we can scale the server farm horizontally via load balancing, scale the database servers horizontally and split them into read/write servers and read-only servers, then load balance the read-only servers.
Scaling via load balancing implies distributing load across multiple server machines. When multiple concurrent requests are received (input queues are main part of load balancer), they are typically distributed among the available machines, usually with a round-robin approach, or (better) by an algorithm that determines which machine has the least active requests being processed.
Software load balancers (such as Network Load Balancer, or NLB) or hardware load balancers (appliances such as a Cisco router) are usually responsible for
less impact on scalability
HW tuning
Product tuning
Code tuning
Design tuning
Figure 3.15: Impact of horizontal and vertical tuning techniques on scalability (source: http://www.diranieh.com/DistributedDesign_1/Scalability.htm)
the algorithm used to distribute load. In theory, the best situation is when re-quests are freely distributed to the most available machine but sessions usually get in the way of this freedom.
The Weda improves the scalability of traditional SOA because of its event - driven asynchronous nature. On the other hand, it has the negative impact on the scalability of the final solution because it depends on sessions. As we will show at the end of this section, some features of Weda binding are to be presented to deal with scalability issues. We want to be able to increase out-put capacity while maintaining session integrity. Because of that Weda session manager implementation should be built with mind of supporting high scala-bility.
It is said that Session management performance is optimal when session data per user is around 2Kb. It degrades if session data is more than that. By definition, an application is Stateful if the server itself has to persist the user connection in order to keep providing the correct data to a single connected client. In Weda, session data per connection and user are minimal. Only in-formation about subsequent message format is held. Every other message ex-change is or can be maintained as it is in stateless environment. It is left on application developer if he makes reuse of connection for storing additional data such as authentication or if the state will be held separately from the con-nection for example in database layer. Replicating a lot of session information between 2 nodes might be simple, and 10 nodes might be possible, but storing additional data to connection or to a session is not very scalable without a little extra work. In this place HTTP based principles for building scalable sites are to be used with the goal of less memory consumption and bigger throughput.
Some application types are less affected by this limitation than another. For example this shouldn’t be problem in real environment with long living client app such as WMS reader.
By relationship of scalability to throughput, one possibility is that only one request thread is granted access to a service instance object instantiated per ses-sion (lock is acquired for the service object while a request is being processed by that object). This could be scalability issue for multithreaded clients (while not impacting throughput of multiple clients) because other calls to the same object are queued in order of receipt at the service subject to the client’s send timeout or the service’s session timeout, if applicable. When the request that owns the lock has completed, and thus released the lock, the next request in the queue can acquire the lock and begin processing. This configuration re-duces the potential throughput at the service in Weda architectural style, but it also yields the least risk for concurrency issues. Better approach for Weda is when no locks are acquired on the service instance and all shared state and re-sources are protected with manual synchronization techniques. This is useful for increasing throughput in Weda. As each connection may require a certain amount of processing, memory allocation, hard disk access, network access, and other overhead, it is highly recommended to limit maximum concurrent sessions. Another recommended technique is to configure timeouts that will al-low you to reclaim resources from sessions that are not currently in use, helping to ensure that idle sessions are not wasting system resources. The number of active sessions allowed SHOULD be weighed against the amount of resources consumed by each session. Although greater scalability can be achieved if new requests are always passed to a server with the most resources, load balancers also SHOULD look at the number of sessions living on a particular server and distribute new sessions to those servers with fewer sessions. For the benefits that sessions bring, this is usually an acceptable cost.
Weda binding SHOULD support sticky session load balancing to main-tain the same channel between client and service, but if a new client channel is created, it can pass an existing context and successfully construct the service in its current state on another machine. Because channel creation is expen-sive, Weda MUST implement the reuse of channel across the proxies in multi-threaded environment. Service SHOULD allow multiple concurrent requests to the same channel. Weda implementation MUST provide configuration for maximum concurrent connections. Weda implementation SHOULD contain a WebSocket server that supports multiplexing on WebSocket layer [91]. Mul-tiplexing MUST NOT be done on Weda layer. We built an alpha implemen-tation Weda API and benchmarked its scalability parameters as described in chapters9,8.
.. Flow control
Here we show how to write Weda clients/servers that don’t overwhelm the re-ceiving side when sending data too quickly. Flow control mechanism prevents
sender from overwhelming receiver. Receiver MUST explicitly inform sender about (dynamically changing) amount of free buffer space . Weda defines a receive window for flow control mechanism that is extended from the spare room in the buffer and counted by substracting a whole input queue buffer size and filled buffer size.
RcvWindow = RcvBufferReadBytes
Sender MUST limit data to RcvWindow. RcvWindow is part of response messages and part of Weda subprotocol defined in chapter3.4. RcvWindow SHOULD be provided as configurable system parameter. We can find right RcvWindow by running benchmarks over the system with RcvWindows turned off. Order, reliable transmission, congestion control are guaranteed by TCP.
The question is if Weda should have any congestion avoidance mechanism other than TCP. Large buffers present on most equipment on the Internet de-feat the ability for TCP to detect congestion in a timely way. This combined with absurd queue lengths can result in RTT that seem to travel several lu-nar distances. Such a mechanism (for example based on timings of PING and PONG messages) can be added in future if needed.
.. Reliability
Services in Weda architectural style are acting over a network with possibly unreliable communication channels. Connections can break and messages can fail to get delivered (or are delivered more than once or in the wrong sequence). Service reliability means the service operates correctly and either does not fail or reports any failure to the service user. Service reliability also means making sure that the service is obtained from a reliable provider so that a level of trust in the service’s accuracy and reliability can be established. WS-ReliableMessaging (WS-RM) [23] proposes a model based on SOAP messag-ing to achieve reliable communication between a service and its consumers.
If reliability is an issue, this standard should be applied. Weda subprotocol MUST NOT provide features for reliable messaging.
.. Extensibility
Extensibility is the ease with which the services’ capabilities can be extended without affecting other services or parts of the system. As this work represents alpha state of architecture style, future growth is expected. New version of this proposal can for example cooperate with WebSocket over SPDY transport [83] which is draft only allowing to share connection with SPDY. Queues can be added and whole system extended by message broker (AMQP). Session manager can be extended by adding session reestablishment mechanism. New Weda policy expressions can be added to represent the new capabilities and requirements of Web services as Policies. This style is open for such extensions because it is built as a layer in whole stack and uses WSDL 2.0 as description.
. Conclusion
We have informally described Weda architectural style in this chapter, appli-cable quality attributes and also its possible enhancements. We used WWW-based architecture ontology entities constrained in their relationships in order to achieve a desired set of architectural properties. Details in this chapter can help to build implementation of WedaAPI so that all requirements are met.
The chapter gave us comprehensive technical and organizational notes about Weda.
. Model based analysis and formal verifica-tion
. Background
.. Model checking
Common design flaws that occur in design of distributed systems are
• Deadlock — all the processes/components are blocked.
• Livelock, starvation — all the processes are doing “useless” computation.
• Underspecification — unexpected reception of messages.
• Overspecification — dead code.
Model checking is a method to algorithmically verify formal systems. This is achieved by verifying if the model, often deriving from a hardware or software design, satisfies a formal specification. A descriptive specification model, in our modeling approach, has as its primary purpose to facilitate description and communication of how a protocol works, and to serve as an executable protocol specification that provides a basis for verification and implementation models. The first step in model-checking requires creation of formal represen-tation of the system. This represenrepresen-tation depends on the model-checking tool to be used for verification.
.. Identification of method and modeling formalism
Various models, such as OWL-S (web ontology language) process model [13], BPEL4WS (business process execution language for web services)[12], and WSCDL (web services choreography description language) [46] exist to de-scribe web services, but most of them are semiformal. Translations are neces-sary to generate formal models that admit mathematical rigors as required by model checkers. Formal models break into two major types: state-transition models and workflow models. State-transition models are widely used to repre-sent both hardware and software systems. Some common languages for system
Formal model
LTL, CTL Property Assertion
State transition Workflow
GA Real-time Workflow Guard reaction
WSAT / SPIN UPPAAL BLAST Blade
Figure 4.1: Models, specifications, and model checkers
representation are PROMELA for SPIN or temporal logic formulas. K.I.F. Si-monsen and L.M.Kristensen did a basic modeling of Websocket protocol using Petri Nets [56].
Figure 4.1 lists the classification of formal models. It also lists the cor-responding specifications (in rectangles) and model checkers (in dotted-line ovals). In state-transition models, a state is viewed as an event. Temporal logic formulas express the temporal relation (happens before or next, etc.) among events.
Expressive and popular formalism for modeling real-time systems is known as Timed automata [62]. SPIN can be used for untimed and UPPAAL for timed systems.
Definition 1 (Timed automaton) is a tupleA = (Q, q0,∑
,E, I, C) where Q is finite set of discrete states (locations)
q0 ∈ Q is the initial discrete state
∑is set of events C is finite set of clock E⊆ Q × B(C) ×∑
×2C× Q is set of timed edges
where B(C) is set of boolean clock constraints involving clocks from C and 2C is powerset of C
I : Q→ B(C) is a function associated with each discrete state Q. System can remain in the same location as long as the invariant is true. Invariants I are downwards closed, in the form: x≤ n, where n is natural number and x ⊂ C is clock variable.
We shall write qg,a,r→ q′ when⟨q, g, a, r, q′⟩ ∈ E.
Definition 2 (Guards) Let C be a set of real valued clocks and I a set of integer valued variables. A guard g over C and I is a formula generated by the following syntax
g ::= c|g ∧ g, where c ∈ (Cc(C)∪ Ci(I))
Cc is set of all clock constraints over C, Ci is set of all integer constraints over I.
B(C, I) stands for the set of all guards over C and I.
In order to study compositionality problems we introduce a parallel com-position of timed automata. In order to get the kind of parallel comcom-position we want, we have to introduce the notion of co-actions, which is done by defining a synchronization function τ.
Definition 3 (Synchronization Set) Let Act be the set of visible actions (a,b...range over Act).
Let τ ⊆ Act × Act be a set of pairs such that:
⟨a, b⟩ ∈ τ ⇒ ⟨b, a⟩ ∈ τ for all a, b ∈ Act
Definition 4 (Parallel Composition). Let A1, A2be two timed automata. Then, the parallel composition (A1|A2)is a timed automaton⟨Q, q0,∑
Note that parallel composition is commutative and associative.
Definition 5 (Deadlock) is a state violating the discrete-progress requirements. A state s ofA is deadlock, if there is no delay δ ∈ R and event edge e ∈ E such that s→δ → sel ′.
One version of temporal logic is computational tree logic (CTL). Com-putation trees are derived from state transition graphs. The graph structure is unwound into an infinite tree rooted at the initial state. It is often used to express properties of a system in the context of formal verification or model checking.
Formulas in CTL are built from atomic propositions (where each proposi-tion corresponds to a variable in the model), standard boolean connectives of propositional logic (e.g., AND, OR, XOR, NOT -¬, ⇒, ⇔, ∧, ∨ logical opera-tors), and temporal operators. All temporal operators are interpreted relative to an implicit ”current state”. There are in general many execution paths (se-quences of state transitions) of the system starting at the current state. The path quantifier indicates whether the modality defines a property that should be true for all those possible paths (denoted by universal path quantifier A) or whether the property needs only hold on some path (denoted by existential path quantifier E).
• A□φ – All: φ has to hold on all paths starting from the current state.
• E♢φ– Exists: there exists at least one path starting from the current state where φ holds.
The term temporal logic is used to describe any system of rules and sym-bolism for representing, and reasoning about, propositions qualified in terms of time. In a temporal logic, statements can have a truth value which can vary in time.
Formally, the problem can be stated as follows: given a desired property, expressed as a temporal logic formula φ, and a model M with initial state q0, decide if M, q0|= φ.
Model checking tools face a combinatorial blow up of the state-space, com-monly known as the state explosion problem.
Definition 6 Reachability problem The reachability problem for timed automata is to decide whether there exists an accepting run of a given automaton.
This problem is known to be PSPACE-COMPLETE [2,21].
.. Identification of model checking tool UPPAAL
UPPAAL is a tool suite for validation and symbolic model-checking of real-time systems. This choice is motivated by the interesting features of UPPAAL tools model-checker. In the current implementation of UPPAAL a system descrip-tion (or model) consists of a collecdescrip-tion of timed automata extended with inte-ger variables in addition to clock variables modeling the finite control struc-tures of the system. The edges of the automata are decorated with three types of labels: a guard, expressing a condition on the values of clocks and integer variables that must be satisfied in order for the edge to be taken; a
UPPAAL is a tool suite for validation and symbolic model-checking of real-time systems. This choice is motivated by the interesting features of UPPAAL tools model-checker. In the current implementation of UPPAAL a system descrip-tion (or model) consists of a collecdescrip-tion of timed automata extended with inte-ger variables in addition to clock variables modeling the finite control struc-tures of the system. The edges of the automata are decorated with three types of labels: a guard, expressing a condition on the values of clocks and integer variables that must be satisfied in order for the edge to be taken; a