WEDA - NEW ARCHITECTURAL STYLE FOR WORLD-WIDE-WEB ARCHITECTURE
Dissertation
Study programme: P – Electrotechnology and informatics Study branch: V – Technical Cybernetics
Author: Ing. Jitka Hübnerová
Supervisor: doc. RNDr. Pavel Satrapa, Ph.D.
Prohlášení
Byla jsem seznámena s tím, že na mou disertační práci se plně vztahuje zákon č. 121/2000 Sb., o právu autorském, zejména
§ 60 – školní dílo.
Beru na vědomí, že Technická univerzita v Liberci (TUL) neza- sahuje do mých autorských práv užitím mé disertační práce pro vnitřní potřebu TUL.
Užiji-li disertační práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tomto případě má TUL právo ode mne požadovat úhradu nákladů, které vynaložila na vytvoření díla, až do je- jich skutečné výše.
Disertační práci jsem vypracovala samostatně s použitím uve- dené literatury a na základě konzultací s vedoucím mé diser- tační práce a konzultantem.
Datum:
Podpis:
Abstract
In this work, the proposal of duplex event-based architectural style is described and tested. This style helps with usabil- ity, processing and performance of web services especially in conjunction with monitoring and alerting applications or ge- ographic systems. This work has a contribution in the area of software architectures, formal modelling and performance en- gineering.
Thesis has theoretical and practical parts. I first give a brief review of SOA 2.0, EDA and ESB ensemble theory. Then I present a detail analysis of our Weda architecture style and its enhancements and discuss for its essence, characteristics, ap- plicable conditions, applicable scope and application domain.
With Weda, service oriented architecture can evolve to event- driven-architecture, while preserving capabilities to communi- cate over the World-Wide-Web. For this purpose we will in- troduce new Web-Event-Driven-Architecture (Weda) architec- tural style, protocol and developed API, which can be estab- lished easily into existing web services stack, so millions of web services can be extended and are not forced to be completely rewritten.
As tests show, impacts of the Weda architectural style is better throughput for web services and benefit of possibility to ex- tend communication to duplex level with client contract with- out needing the client to publish a public endpoint over the Internet. Thanks to this discovery, we will describe a Weda’s event processing capabilities such us complex event processing and we will bring them to event propagation patterned WWW ESB proposal, which can be integrated into HTTP servers and as well to SaaS model of public clouds. We will mention a prac- tical use case scenario. Work provides quality attributes mea- surements conducted on our implementation.Weda is modeled as a network of timed automata which results in a compact and intuitively appealing specification and provides its formal val- idation and verification.
Keywords
software architecture, web services, SOA 2.0, event processing, web socket, senzor web, GIS, performance, timed automata
Abstrakt
V této disertační práci je popsán a otestován návrh du- plexního událostně řízeného architekturálního stylu. Tento styl rozšiřuje použitelnost webových služeb a zlepšuje jejich výkon a zpracovávání, a to zvláště ve spojení s monitorovacími a pohotovostními aplikacemi nebo geografickými systémy.
Práce přispívá zejména do oblasti softwarových architektur, formálního modelování a řízení výkonu.
Disertační práce má teoretické i praktické části. Nejprve je předložen přehled teorie architektur SOA 2.0, EDA a ESB.
Následně je detailně analyzována koncepce architekturálního stylu Weda a jeho rozšíření, diskutována jeho podstata, charak- teristiky, podmínky, rozsah a aplikační doména. S použitím ar- chitekturálního stylu Weda se SOA snadno rozšíří na událostně řízenou architekturu, a to při zachování schopnosti komuniko- vat přes WWW. Za tímto účelem práce představuje jak speci- fikaci tohoto stylu, tak protokol a v neposlední řadě vyvinuté API, které může být snadno zařazeno do zásobníku vrstev stá- vajích služeb tak, že miliony služeb mohou být pouze rozšířeny bez nutnosti jejich přeprogramování.
Jak ukazují testy, dopadem architekturálního stylu Weda je vyšší propustnost webových služeb a možnost rozšíření ko- munikace na obousměrnou aniž by byl klientský uzel nu- cen publikovat veřejný port. Dále práce popisuje, jak lze do globálně přístupného informačního systému zahrnout schop- nost komplexního zpracovávání událostí (samostatný obor) a transformuje tento návrh do návrhu ESB sběrnice s vzorem propagace událostí, jejíž běh je možný přes WWW. Je tak integrovatelná do HTTP serverů a také SaaS modelu veře- jných cloudů. Prakticky popíšeme a ukážeme případ užití na příkladu senzorových webů. Práce nám poskytne výsledky měření různých atributů kvality získaných vlastním měřícím programem na vlastní implementaci. Tyto výsledky jsou an- alyzovány s použitím teorie pravděpodobnosti a matematické statistiky. Weda styl je v práci formálně modelován, a to jako síť časových automatů, čímž práce zaručuje jeho kompaktní specifikaci, formální validaci a verifikaci.
Klíčová slova
sw architektury, webové služby, SOA 2.0, řízení událostí, web socket, senzorový web, GIS, měření výkonu, časové automaty
Acknowledgement
I would like to thank my husband and whole family for never- ending support and tolerance especially in the last year during which I spent more time with my laptop than with them. I promise to make up for it a thousand times.
I also thank to all my friends, Ing.Subhi Brož, Ph.D., MBA for the motivation to complete the job and to my supervisor doc.
RNDr. Pavel Satrapa, Ph.D. for the numerous revisions and insightful comments.
Contents
List of Abbreviations . . . 10
List of Figures . . . 12
List of Tables . . . 14
1 Introduction 15 1.1 Problem statement and motivation . . . 15
1.2 Contribution of this dissertation . . . 16
1.2.1 Contributions in the area of software architectures . . . . 16
1.2.2 Contributions in the area of formal modelling . . . 16
1.2.3 Contributions in the area of performance engineering . . 16
1.3 Organization . . . 17
2 Background 18 2.1 Motivation . . . 18
2.2 Service oriented architecture (SOA) . . . 18
2.3 Webservices (WS) . . . 19
2.4 Quality of service (QOS) and service level agreements (SLA) . . 19
2.5 Event driven architecture (EDA) . . . 20
2.6 SOA 2.0 . . . 22
2.7 Enterprise service bus (ESB) . . . 22
2.8 Composite services and service workflows . . . 25
2.9 The Websocket protocol . . . 25
2.10 Sensor web . . . 28
2.11 Previous and related work . . . 29
3 Informal description of Weda architectural style 32 3.1 Motivation . . . 32
3.2 Comparison of Web services architectural styles . . . 35
3.3 Weda channel stack . . . 38
3.3.1 Overview . . . 38
3.3.2 Weda gateway . . . 38
3.3.3 Weda endpoints . . . 40
3.3.4 Addressing . . . 40
3.3.5 Weda binding . . . 42
3.3.6 Weda contract - format, data . . . 42
3.3.7 Weda contract - MEP, channels . . . 43
3.3.8 Weda description . . . 45
3.3.9 Considerations about usability of WebSocket transfer for messaging . . . 47
3.3.10 Considerations about HTTP 2.0 cooperation . . . 49
3.4 Weda subprotocol . . . 51
3.4.1 Transport . . . 51
3.4.2 Serialization. . . 51
3.4.3 Payload format . . . 51
3.4.4 Handshake . . . 51
3.4.5 Message types. . . 52
3.4.6 Encoder . . . 53
3.5 Messaging elements of Weda binding . . . 54
3.5.1 Service lifetime . . . 54
3.5.2 Asynchronicity . . . 54
3.5.3 Client notifications and services. . . 55
3.5.4 Pipelining . . . 56
3.6 Weda event processing layer . . . 58
3.6.1 Weda event processor contributions to EDA architecture 58 3.6.2 Event processing and metadata services . . . 59
3.6.3 Topic management . . . 62
3.6.4 Complex event processing . . . 63
3.6.5 Event propagation patterned WWW ESB proposal . . . . 65
3.6.6 Use-case scenario . . . 67
3.7 Some quality attributes . . . 70
3.7.1 Overview . . . 70
3.7.2 Performance . . . 70
3.7.3 Scalability . . . 71
3.7.4 Flow control . . . 73
3.7.5 Reliability . . . 74
3.7.6 Extensibility . . . 74
3.8 Conclusion . . . 75
4 Model based analysis and formal verification 76 4.1 Background . . . 76
4.1.1 Model checking. . . 76
4.1.2 Identification of method and modeling formalism . . . . 76
4.1.3 Identification of model checking tool UPPAAL . . . 79
4.2 Modeling the Weda architectural style . . . 81
4.2.1 Architecture of the single node model . . . 81
4.2.2 Weda Gateway Host Initialization . . . 82
4.2.3 Weda Gateway SessionChannelListener . . . 83
4.2.4 Weda Gateway SessionChannelManager . . . 84
4.2.5 Weda Gateway SessionChannelWire . . . 86
4.2.6 Full-duplex Weda channel. . . 87
4.2.7 Client-side modeling . . . 90
4.2.8 SessionChannelFactory . . . 90
4.2.9 Client . . . 90
4.2.10 Global Variables . . . 92
4.2.11 Weda model simulation . . . 94
4.3 Verification . . . 94
4.4 Conclusion . . . 95
5 Adapting applications to Weda API 97 5.1 Overview . . . 97
5.2 Programming model . . . 97
5.2.1 Server, synchronous services . . . 97
5.2.2 Synchronous consumer . . . 98
5.2.3 Asynchronous services . . . 99
5.2.4 Asynchronous consumer . . . 99
5.3 Conclusion . . . 99
6 Implementation 101 6.1 Overview . . . 101
6.2 API description . . . 101
6.2.1 Weda transport binding . . . 102
6.2.2 Weda subprotocol . . . 103
6.2.3 Event processing layer . . . 103
6.3 Future releases . . . 103
6.4 Conclusion . . . 103
7 Experimental systems and case studies 105 7.1 Overview . . . 105
7.2 Server side . . . 106
7.2.1 Database layer . . . 107
7.2.2 Data acess layer . . . 107
7.2.3 Web service . . . 107
7.2.4 Weda API . . . 107
7.3 Thin client. . . 108
7.4 Thick client . . . 109
7.5 Conclusion . . . 112
8 Distribution of response time instability 113 8.1 Motivation . . . 113
8.2 Method and settings . . . 113
8.3 Performance analysis . . . 115
8.4 Hypothesis checking technique and Goodnes-Of-Fit analysis . . 116
8.5 Performance simulation . . . 122
8.6 Conclusion . . . 125
9 Performance testing 126
9.1 Overview . . . 126
9.2 Measurement results . . . 127
9.2.1 Test case 1 – constant-time bursts from 1 client . . . 127
9.2.2 Test case 2 – variable publish rate from 1 client . . . 131
9.2.3 Test case 3 – constant sample count from growing num- ber of clients . . . 131
9.2.4 Test case 4 – variable clients and constant-time bursts . . 134
9.2.5 Test case 5 – asynchronicity differences suppressed . . . . 139
9.3 Conclusion . . . 139
9.3.1 Findings on the throughput attribute . . . 139
9.3.2 Findings on the scalability attribute . . . 141
9.3.3 Findings on the response time attribute . . . 141
10 Conclusions and future work 143 10.1 Summary . . . 143
10.2 Future work . . . 144
10.3 Publications . . . 145
10.3.1 Articles . . . 145
10.3.2 Workshops . . . 146
Bibliography . . . 147
Appendices 154
A Weda single node simulation 155
B Verification results 156
C Example duplex service contract 157
D Observations Data Model (ODM) and its EDMX model 163
E WS-eventing scheme 165
List of Abbreviations
AMQP Advanced messaging and queueing protocol API Application programming interface
BPEL4WS Business Process Execution Language for Web Services CEP Complex event processing
CORS Cross Origin Resource sharing EDA Event driven architecture EPL Event processing language ESB Enterprise service bus
GIS Geographic Information System GOF Goodness Of Fit
HTTP Hypertext transfer protocol
IANA Internet Assigned Numbers Authority JMS Java Message Service
MEP Message Exchange Patterns
MTOM Message Transmission Optimization Mechanism MVVM Model-View-ViewModel
NLB Network Load Balancer OGC Open Geospatial Consortium ORM Object Relational Mapper
OWL-S Semantic Markup for Web Services POX Plain old XML object
QA Quality attribute
RAD Rapid Application Development RAM Random access memory
REST Representational State Transfer RFC Request for comment
RPT Request processing time RTT Round-trip delay time
RT Response time
SAAS Software as a Service SAS Sensor Alert Service SLA Service-Level Agreement SOA Service oriented architecture SOAP Simple object access protocol
SOA2.0 Event-driven Service oriented architecture SOS Sensor observation service
SSL Secure Sockets Layer SUT System under test
SWE Sensor Web Enablement
TCP Transmission Control Protocol TLS Transport Layer Security
UDDI Universal Description, Discovery and Integration URI Uniform Resource Identifier
WFS Web Feature Service
WS WebSocket
WSCDL Web Services Choreography Description Language WMS Web Map Service
WWW World Wide Web
WSDL Web Services Description Language XML Extensible Markup Language
XMPP Extensible Messaging and Presence Protocol
List of Figures
1.1 Blackbox overview of Weda . . . 16
2.1 Relationship between components in SOA . . . 19
2.2 Relationship between components in EDA . . . 21
2.3 WWW and ESB topologies . . . 22
2.4 ESB interaction patterns . . . 24
2.5 ESB mediation patterns . . . 24
2.6 Websocket closing handshake . . . 27
2.7 Basic Observation structure . . . 30
3.1 High-level process view of Weda infrastructure . . . 34
3.2 WEDA gateway . . . 39
3.3 Relationship to an endpoint . . . 40
3.4 WEDA endpoint . . . 40
3.5 WEDA endpoint addressing . . . 41
3.6 WEDA channel . . . 45
3.7 Dependency of WebSocket overhead. . . 48
3.8 Pipelining . . . 57
3.9 Event processing layer . . . 59
3.10 High-level process view of Weda event processor and its relation- ship to EDA components . . . 60
3.11 Batch time widow . . . 65
3.12 Event propagation patterned WWW ESB topology . . . 68
3.13 Use case scenario . . . 69
3.14 QA . . . 70
3.15 Scalability tuning techniques . . . 72
4.1 Models, specifications, and model checkers . . . 77
4.2 TCTL Formula syntax . . . 81
4.3 Host initialization model. . . 83
4.4 Weda Gateway Session Channel Listener model. . . 83
4.5 Session Channel Manager model. . . 85
4.6 Session Channel Wire model. . . 87
4.7 WedaChannelInput model . . . 88
4.8 WedaChannelOutput model. . . 88
4.9 SessionChannelFactory model. . . 91
4.10 Client . . . 92
7.1 Overview of experimental systems . . . 106
7.2 Experimental system with thin client interface . . . 108
7.3 Experimental system with thick client interface . . . 109
8.1 Benchmark setup . . . 114
8.2 Performance trends and probability density of RT, RTT, RPT . 115 8.3 PDF and CDF fit on RT, RTT, RPT . . . 122
8.4 PDF and CDF fit on Group1 and 2 of RT, RTT, RPT . . . 123
9.1 TC1 (constant burst) – throughput . . . 129
9.2 TC1 (constant burst) – response time . . . 129
9.3 TC1 (constant burst) – throughput in KB/s . . . 130
9.4 TC1 (constant burst) – Standard deviation . . . 130
9.5 TC2 (variable rate) – throughput . . . 131
9.6 TC2 (variable rate) – 90th percentil – response time . . . 132
9.7 TC2 (variable rate) – minimal response time . . . 132
9.8 TC2 (variable rate) – maximal response time . . . 133
9.9 TC2 (variable rate) – standard deviation . . . 133
9.10 TC2 (variable rate) – throughput in KB/s . . . 134
9.11 TC3 (variable clients and constant burst) – throughput . . . 134
9.12 TC3 (variable clients and constant burst) – throughput in KB/sec135 9.13 TC3 (variable clients and constant burst) – response time . . . . 135
9.14 TC3 (variable clients and constant burst) – standard deviation . 136 9.15 TC3 (variable clients and constant burst) – maximum response time . . . 136
9.16 TC3 (variable clients and constant burst) – minimal response time . . . 137
9.17 TC4 (variable clients and timed burst) – throughput . . . 137
9.18 TC4 (variable clients and timed burst) – response time . . . 138
9.19 TC4 (variable clients and timed burst) – standard deviation . . 138
9.20 TC5 (variable clients) – response time . . . 139
9.21 TC5 (variable clients) – throughput . . . 140
9.22 TC5 (variable clients) – throughput in KB/sec . . . 140
A.1 Weda single node simulation. . . 155
B.1 UPPAAL showing the verification results of model . . . 156
D.1 Observations Data Model (ODM) . . . 163
D.2 EDMX model . . . 164
List of Tables
2.1 List of selected available ESB solutions . . . 23
2.2 History of The Websocket protocol . . . 26
2.3 Table of Websocket servers . . . 30
3.1 Weda’s major architectural ontology entities . . . 33
3.2 Comparison of Web services architectural styles . . . 37
3.3 Weda MEPs . . . 43
3.4 Rules for binding the MEPs . . . 44
3.5 Weda state machine’s states . . . 45
3.6 WSDL 2.0 parts . . . 46
3.7 Weda/WebSocket fragmentation rules . . . 48
3.8 Weda message types . . . 52
3.9 Subprotocol specific errors . . . 53
4.1 Correspondence between CTL and UPPAAL query language syntax . . . 80
8.1 Performance statistics: RT, RPT, RTT . . . 116
8.2 RT Goodness Of Fit approximation . . . 119
8.3 RTT Goodness Of Fit approximation . . . 120
8.4 RPT Goodness Of Fit approximation . . . 121
9.1 Test scenarios . . . 128
. Introduction
. Problem statement and motivation
Web services are increasingly gaining acceptance as a framework for facilitat- ing application-to-application interactions within and across enterprises. SOA is widely used architecture mainly because of spread of web services. SOA 2.0 is theoretical concept which is not practically used today mainly because of technological and security limits.
As WebsocketAPI becomes W3C and browser standard in the near future, we stay in front of the task of using new communication channel for SOA 2.0 (event-driven SOA) and try to create more decoupled World-Wide-Web based distribution system. Because of nature of web services and libraries, it isn’t possible to port existing services one-by-one to a new channel. Special con- straints must be developed. New opportunities should be presented. The true bi-directional capability offered by WebSockets is a first for any HTTP-borne protocol. It is something that neither SOAP nor REST have.
As complexity of protocols grows, there is still less chance that some even good protocol ([86], [1], [4]) becomes widely popular. The world of applica- tion integration over the public Internet is very conservative, and it is logical output of number of interested sides, which have to communicate with each other. From this assumption we come out to the concept of Weda. Weda tries to deal with the trend of growing amount of data transferred via WWW from the application architecture point of view and growing number of functionally coupled nodes in the network. Presented style has been strictly designed to fill a gap in layered structure of web service’s protocol stack enabling a new features whilst preserving the existing. Such a concept is backward compati- ble and has bigger chance for success. It is also capable for dealing with new hosting environments (public clouds) and extensions such as possibility to ex- tend communication to duplex level with client contract without needing the client to publish a public endpoint over the Internet. Programming-language specific API’s can be built to establish a Weda into the stack.
A motivation use-case for such a solution can be building part of complex GIS systems and/or public sensor web. Number of sensor data is growing and more people want to see the data from the sensors online via the WWW.
Consortium OGC has been developing a new standard of Sensor Observation Service for sensor web and another standard Sensor Alert Service. If such
Web-service provider (server)
WedaAPI (client)
WedaAPI Consumer
Websocket / Weda subprotocol
HTTP
Figure 1.1: Blackbox overview of Weda
a web-service standard meets the new binding possibilities, alerting become widely accessible and GIS viewers and sensors can improve user-experience while loading/publishing sensor data or loading WMS tiles as well.
Simply, any alerting or monitoring solution can benefit from Weda ar- chitectural style.
. Contribution of this dissertation
.. Contributions in the area of software architectures
The main objective of this thesis is to provide a practical solution for building SOA 2.0 based distributed systems which are interconnected via World-Wide- Web and deployable to Cloud. Second objective is to find its advantages and disadvantages and opportunities by dealing with its performance, scalability, extensibility and internal issues. When given a name Weda, a coordinated set of architectural constraints becomes an architectural style. Informal descrip- tion can be translated to RFC document.
.. Contributions in the area of formal modelling
Another goal is to provide a methodology on how to create a checkable model and its formal verification of Weda components and Websocket subprotocol.
Websocket protocol as new protocol isn’t formally modeled at the moment.
One can use the results to model another subprotocol specification or Web- socket extension. Results prove that the system of Weda components is viable and creates a compact and intuitively appealing specification.
.. Contributions in the area of performance engineering
Third objective is to measure referential implementation and experimental sys- tem. One can use these results to ensure that his adoption of system is efficient and scalable. While no public tool is available for such performance analysis, I developed a multithreaded load tester SW tool for dealing with the task. Mea- surement results were used to find a methodology for predicting a RTT for any WebSocket subprotocol and to provide a random number generator that simulates the results for other theoretical studies. Work presents the results for Weda architecture style and its subprotocol.
. Organization
This work is designed to enable us to do comprehensive picture of the whole architectural style. We will talk briefly about the conceptual and also about the technical infrastructure and we will bring practical application view of the design. The remainder of the thesis is organized in the following way:
• Chapter 2 introduces the domain and the background of the research.
• Chapter 3 contains informal description of the architectural style. In future it can be translated to RFC draft and used for dealing with imple- mentation issues.
• Chapter 4 presents a framework that can be used to model and verify Weda architectural style formally.
• Chapter 5 presents a way to adopt existing application to Weda API and so to Weda-style.
• Chapter 6 presents a C# programming language WedaAPI implementa- tion.
• Chapter 7 contains description of experimental systems that were built upon the implementation.
• Chapter 8 contains an application of theory of probability and mathe- matical statistics to study performance issues. Input data were gained from long running test and the results are used to find a prediction for- mula of system’s response time.
• Chapter 9 presents results of number of measurements that compare performance quality attributes of Weda against SOAP and REST sys- tems.
• Chapter 10 concludes the lessons learned and asks questions for future work.
. Background
. Motivation
The following sections contains a description of the basic concepts required for understanding the context of the problem addressed in the thesis. Experienced reader can skip this part.
. Service oriented architecture (SOA)
Old approach for application-to-application interaction is object-oriented ar- chitecture that usually requires pass-by-reference facilities and usually middle- ware specific data format description which involves tight coupling between client and server. So it is best for “closed” systems within a single organiza- tion. SOA [28][55] is one type of modern loosely coupled software architec- ture patterns. SOAs as architectures are not well defined and there is not much architectural guidance on how to design SOA. But vendor specific APIs for designing SOAs exists (such as WCF [63]). Many of guides focus target spe- cific technologies, which are used to build the SOA, for example web services.
SOA in principle is decomposition of business functions with command-and- control nature. It comprises components, services, and processes. One ore more orchestrated services build together an automation process. SOAs are in technological manner loosely coupled. But in functional level they are tightly coupled because all application logic is hidden behind the interface.
An application uses SOA only if the three following conditions are met:
1. Service description is published. To be accessible, a service description must be published so that it can be discovered and invoked by a service consumer.
2. Service is discoverable. A service requestor locates a service by querying the service registry for a service that meets its criteria.
3. Service is invokable. After retrieving the service description, the service consumer proceeds to invoke the service according to the information in the service description.
service
consumer service
messages contracts endpoint
policy
binds to
understands
sends / receives
governed by
exposes
implements
sends / receives serves
describes adheres to
legend
relation component
Figure 2.1: Relationship between components in SOA
. Webservices (WS)
A web service [39] is a well known application of SOA designed to support inter-operable machine-to-machine interaction over a network, identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other soft- ware applications using XML based messages via Internet-based protocols. At the time of writing, web services are widely used technique which standardizes many aspects of distributed processing and communication over the World- Wide-Web. The appeal of web services over other interoperability standards, such as CORBA [38] or sockets [78], is the simplicity and flexibility of the ar- chitecture, which builds upon XML technologies. It is used widely over the World-wide-web, mainly thanks to SOAP [65] or REST [32] webservices which build on RPC or REST architectural styles.
. Quality of service (QOS) and service level agree- ments (SLA)
The term QoS, as it is most commonly used in practice, originated in the fields of networking, telecommunications and distributed multimedia. Even here the precise definition varies. When modeling SOA applications and services, often the term quality of service (QoS) is used to refer to the collection of quality re- quirements for a service. QoS should be modeled [44] because these quality requirements can then be acknowledged by stakeholders. Different services can provide the same functionality for consumers, so QoS specifications of these services are essential in determining the most suitable services for con- sumers [3]. With respect to SOA QoS often covers security, performance, availability, reliability and privacy. The importance of a certain quality as-
pect depends on the context of the project in which the SOA is designed. For example reliability indicator can be defined as:
Reliability = SuccessfullServiceInvocations AllServiceInvocations
A SLA document defines assertions of a service provider to perform a service according to agreed guarantees for quality attributes, such as response time and throughput, and measures to be taken in case of deviation and failure to meet the asserted service guarantee, such as, for example, a notification of the service customer.
. Event driven architecture (EDA)
In 2003, Gartner introduced [76] a new terminology to describe a design paradigm based on events: Event-Driven Architecture (EDA). EDA [29] [75], [14] defines a methodology for designing and implementing applications and systems in which events are transmitted between decoupled software compo- nents and services. EDA introduces long-running asynchronous process capa- bilities. The use of EDA can in some cases overcome temporal non-availability of the service (with some other assumptions to achieve this), but interestingly it allows clients to subscribe to some interesting topics, and write application logic, that reacts and analyzes the data from occurring events. Event is a no- table thing that happens inside or outside the business and may signify a prob- lem, an opportunity, a threshold, or a deviation. EDA had many forms by the years when used in local networks and now it is often discussing together with SOA and how these two can interact. This can be very interesting feature when used on World-Wide-Web environment for many of use-cases.
EDA does not replace, but rather, complements the SOA. While SOA is generally a better fit for a request/response exchange, EDA terminology intro- duces long-running asynchronous process capabilities. It is a style of applica- tion architecture centered on an asynchronous “push”- based communication model. By its nature, an event-driven architecture is extremely loosely cou- pled, and highly distributed. Event Metadata architecture includes both an event specifications and event processing rules. Event specifications must be made available to event generators, event format transformers, event process- ing engines, and subscribers. While no standards currently exist for event definition and processing notation, it is only a matter of time. Weda architec- ture style achieves this by defining Metadata processing services as shown in next chapters. Event sinks provide a means of receiving programmatic notifi- cations when events occur that meet the criteria specified by a statement. As we will show, subscribed clients are the sinks in Weda. An application uses EDA only if the three following conditions are met:
1. Event objects are pushed. Event objects are sent from an event source to the event consumer in asynchronous messages at times determined by
legend
relation component
decomposition event
event object
event metadata architecture
source target
event generator
event channel
event procesor governed
by
message broker
CEP engine
implements exposes generate/
publish
processed by
sink
processed by
accepts/
subscribes
accepts/
subscribes pathway
for style
used consumed by
Figure 2.2: Relationship between components in EDA
the event source. Pushing event objects proactively reduces latency (the time required to respond to an event), compared to waiting for consumers to pull event objects (for example, by repeatedly asking if any new data is available = polling). The latency of a pull-based system increases as the time between polling requests increases, but frequent polling may be impractical because of its overhead.
2. Components process events on arrival. An event consumer responds as soon as it gets an event object. An end-to-end process can respond in a timely manner only if each stage of the process executes when it receives an event object rather than waiting for a scheduled time. Of course, dur- ing periods of high load, event objects may arrive faster than they can be processed; in such cases an event object is processed as soon as possible.
3. Event objects do not specify operations. An event object does not specify the operation that a consumer of the object must perform upon receiving the objects. This decreases the logical coupling between sources and consumers of event objects. The source simply sends a message report- ing that an event has happened. The logic to decide what to do about the event is embodied in the consumer (or consumers). Therefore develop- ers have the flexibility of changing or adding event consumers without modifying sources. By contrast, remote procedure call (RPC) mecha- nisms and most request/reply SOA services include a method name on which the service requestor and service provider must agree by contract.
So both requestor and provider must be changed in lock step. The en-
hanced “plug ability” of EDA systems is a key advantage over common request/reply systems.
. SOA .
SOA 2.0 or event-driven SOA is the combination of event-driven and service- oriented architectural paradigms. It is theoretical concept withou practical implementation at this moment.
SOA + EDA = SOA2.0
. Enterprise service bus (ESB)
Enterprise service bus [15] is one of the architectural topologies that uses a common messaging bus to integrate enterprise computer applications and can provide mixing and matching of services. To do this, we first bind the existing (and long lasting) services to the ESB. This basic idea is exactly the same as in EAI [60] message brokers. The main difference between ESB and EAI is that EAI message brokers were designed as monolithic centralized components, whereas in ESB, the single communication bus is purely logical and even if it still provides a centralized management facility, the infrastructure can be possibly distributed across the network. This makes ESB more reliable and scalable. ESB represents a lightweight, flexible, standards-based, platform- independent, distributed alternative to the traditional monolithic bus-based proprietary EAI solutions.
Figure 2.3: WWW and ESB topologies
Essentially, the ESB represents an additional layer, shielding the services from direct invocations. The fast and cheap integration of existing systems is the primary advantage (depending on licensing politics). Changes of re- quirements can be managed quickly. Messages processing is the one of main strengths of ESB, including message routing, protocol mediation, message transformation and message handling.
Building ESB-based solutions is classified with number of patterns [50].
Table 2.1: List of selected available ESB solutions
Product Vendor Connection
Matrix Busi- ness Works
TIBCO SOAP, EMS, JMS, Rendezvous, MQ, BPEL
MULE ESB Open-source, MULE Source, Inc.
SOAP, REST, JMS, MQ, JBI, AQ, Caching, 10 JavaSpaces, GigaS- paces, Email, IM, JCA, AS400 Data Queues, System I/O.
Open ESB Open-source, Sun Microsys- tems
JBI, JCA, JAX-RPC, JAX-WS
Sonic ESB Progress Soft- ware
JMS, SOAP, JMX Websphere
ESB
IBM JMS, MQ, SOAP; requires addi- tional adapters to interface with other products and legacy protocols;
requires Websphere to work AquaLogic Ser-
vice Bus
BEA JMS, SOAP, JMX, MQ, Email
Talend ESB Open-source, Talend
• Interaction patterns enable service interaction points to dispatch mes- sages to, or receive messages from the bus. By event propagation interac- tion pattern events may be anonymously distributed to an ESB-managed list of interested parties. Services may be able to add themselves to the list.
request/reply request/multi-reply event propagation
Figure 2.4: ESB interaction patterns
• Mediation patterns enable the manipulation of message exchanges. It is the most widely used model.
Protocol switch Transform Enrich Route Distribute Monitor Correlate
Figure 2.5: ESB mediation patterns
Protocol switch mediation pattern enables service requesters to dispatch their messages using a variety of interaction protocols or APIs, such as SOAP/HTTP, SOAP/WEDA, REST/WEDA, JMS and trans-codes requests into the targeted service provider’s format. It can be applied at the requester or the provider end of an interaction, at both ends, or anywhere in between.
Transform mediation pattern translates the message payload (content) from the requester’s schema to the provider’s schema. It may include enveloping, de- enveloping, or encryption. Enrich augments the message payload by adding information from external data sources, such as customization parameters de- fined by the mediation, or from database queries. Route changes the route of a message, selecting among service providers that support the requester’s in- tent. Selection criteria can include message content and context as well as the target’s capabilities. Distribute distributes the message to a set of interested parties and is usually driven by the subscriber’s interest profiles. Monitor ob- serves messages as they pass through the mediation unchanged. It can be used to monitor service levels, assist in problem determination or meter usage for subsequent billing to users, or record business - level events, such as purchases above a certain dollar value. It can also be used to log messages for audit or for subsequent data mining. Correlate derives complex events from message or event streams. It includes rules for pattern identification and rules that react to pattern discovery, for example, by generating a complex event derived from content of the triggering event stream.
. Composite services and service workflows
Service composition implies combining multiple services into a new service, also known as a composite service. Composite services are responsible for co- ordinating the work of composition participants, managing their control and data flow. Workflow languages can be viewed as 4G languages [61], as they appear to be highly platform independent languages for describing composite business processes. However, at the same time workflow languages are very expressive, e.g. BPEL4WS is Turing complete [27]. Adopting workflow lan- guages for specifying composite services provides a set of advantages over so- lutions employing canonical programming languages, such as Java, C# and others. Orchestration models specify the order of service invocations depend- ing on conditions. Models can be composed by many of patterns such as Se- quence, Parallel split, Exclusive choice or Loop and modeled with number of abstraction models and languages such as UML activity diagrams, state- charts, petri-nets, pi-calculus, activity hierarchies or rule-based orchestration approaches.
. The Websocket protocol
Websockets is a technology that provides bi-directional, full duplex commu- nication over a single TCP socket. TCP is built for long-lived flows, so with HTTP the more connections, the shorter flows we have. TCP congestion con- trol doesn’t have time to ramp up. Using the Websocket connection for long lived application-to-application scenarios can be advantageuous (not only) for this reason.
Websockets are designed to be implemented in web browsers and web servers. One of the goals is to avoid long polling connections between clients and server which have a negative impact on browser usability and bandwidth usage. Relevant specifications today are:
• The WebSocket API [43]: Draft defines the interface for working with WebSockets in web browsers. The access to basic functionality is pro- vided via JavaScript.
• The WebSocket Protocol [30] (RFC6455): Standard proposal defines the lightweight wire protocol on top of TCP and the initial upgrade process from a HTTP-based handshake. This specification includes ref- erences to various registries at the Internet Assigned Numbers Author- ity (IANA), combined under the WebSocket Protocol Registries [51]. A short history of protocol is outlined in table 2.2.
Websockets have the advantage of using a single TCP socket for the bi- directional communication. The protocol is defined in the application layer, and it can be used to overcome restrictions applied to the transport layer. The
Table 2.2: History of The Websocket protocol
date document-name comment
1 January 2009 draft-hixie-
thewebsocketprotocol-00
First draft from Ian Hickson.
6 May 2010 draft-hixie-
thewebsocketprotocol-76
Latest Hixie-draft.
23 May 2010 draft-ietf-hybi-
thewebsocketprotocol-00
First HyBi-draft.
11 January 2011 draft-ietf-hybi-
thewebsocketprotocol-04
Resolved severe pro- tocol vulnerability.
30 September 2011 draft-ietf-hybi-
thewebsocketprotocol-17
Latest HyBi-draft.
12 December 2011 RFC6455 Proposed standard.
Websocket protocol features a HTTP-compatible handshake and therefore the traffic generated is similar to the one generated through HTTP. It traverses firewalls, proxies, and routers seamlessly and leverages Cross-Origin Resource Sharing (CORS). The communication channel can be protected against eaves- dropping with TLS, much like HTTPS. The default ports are 80 or 443, such that enterprises are not required to open additional ports in their firewalls.
The initial handshake is done via HTTP(s). Afterwards the connection is “up- graded” and the TCP connection remains open as WebSocket channel, where the lightweight WebSocket protocol takes over. Heartbeat is needed otherwise it gets disconnected after 300s by default.
Sub-Protocols are application-level extensions that define how the payload must look like. WebSockets can be used as transport layer for any protocol.
Status codes according to RFC6455 [30] and IANA WebSocket Close Code Number Registry [51]:
• 1000 Normal closure; the connection successfully completed whatever purpose for which it was created.
• 1001 The endpoint is going away, either because of a server failure or because the browser is navigating away from the page that opened the connection.
• 1002 The endpoint is terminating the connection due to a protocol error.
• 1003 The connection is being terminated because the endpoint received data of a type it cannot accept (for example, a text-only endpoint received binary data).
• 1004 The endpoint is terminating the connection because a data frame was received that is too large.
Websocket in-band closing handshakeTCP closing handshake
TCP endpoint TCP endpoint
TCP ACK TCP ACK TCP FIN
TCP FIN
Websocket close frame
Websocket close frame
Websocket close status codes
0000 - 999 Reserved and not used
1000-2999 - Reserved for Websocket protocol 3000-3999 - Reserved for libraries & applications 4000-4999 - Reserved for private use
Figure 2.6: In-band WebSocket closing handshake before TCP connection terminates
• 1005 Reserved. Indicates that no status code was provided even though one was expected.
• 1006 Reserved. Used to indicate that a connection was closed abnormally (that is, with no close frame being sent) when a status code is expected.
• 1007 The endpoint is terminating the connection because it has received data within a message that was not consistent with the type of the mes- sage.
• 1008 The endpoint is terminating the connection because it has received a message that violates its policy. This is a generic status code.
• 1009 The endpoint is terminating the connection because it has received a message that is too big for it to process.
• 1010 The endpoint (client) is terminating the connection because it has expected the server to negotiate one or more extension, but the server didn’t return them in the response message of the WebSocket handshake.
• 1011 Internal error. The server is terminating the connection because it encountered an unexpected condition that prevented it from fulfilling the request.
• 1015 TLS handshake error.
. Sensor web
Scientists have long understood the importance of quality time series observa- tions for conducting research and analyzing data. There is a growing demand for visual analysis provided by web-based client/server systems and even on mobile devices. Web accessible sensor networks of all types (flood gauges, air pollution monitors, stress gauges on bridges, mobile hearth monitors) and archived sensor data that can be discovered, accessed and, when applicable, controlled using open standard protocols and interfaces (APIs).
The Geospatial Consortium (OGC) has successfully introduced various standards for web-services dealing with spatial data, among which the most prominent are the Web Feature Service (WFS) and the Web Map Service (WMS).
OGC SWE standards [8] enable web-based discovery, exchange and pro- cessing of sensor observations, as well as tasking of sensors systems. The mod- els, encodings, and services of the SWE architecture enable implementation of interoperable and scalable service-oriented networks of heterogeneous sen- sor systems and client applications. Wildfires, river basins, tsunami alerts, and environmental risk management are just some of the uses of OGC’s interoper- ability framework for Web-based access and control of sensors and sensor data.
SWE standards are being harmonized with other OGC standards for geospa- tial processing. The vision is to define and approve the standards foundation for “plug-and-play” Web-based sensor networks. The functionality includes:
• Discovery of sensor systems, observations, and observation processes that meet an application or users immediate needs.
• Determination of sensor’s capabilities and quality measurements.
• Access to sensor parameters that automatically allow software to process and geolocate observations
• Retreival of real-time or time-series observations and coverages in stan- dard encodings.
OGC SWE includes the following pending OpenGIS® Specifications:
1. Observations & Measurements Schema (O&M) – Standard models and XML Schema for encoding observations and measurements from a sen- sor, both archived and real-time.
2. Sensor Model Language (SensorML) – Standard models and XML Schema for describing sensors systems and processes; provides informa- tion needed for discovery of sensors, location of sensor observations, pro- cessing of low-level sensor observations, and listing of taskable proper- ties.
3. Transducer Markup Language (TransducerML or TML) – The concep- tual model and XML Schema for describing transducers and supporting real-time streaming of data to and from sensor systems.
4. Sensor Observations Service (SOS) [69, 70]- Standard web service in- terface for requesting, filtering, and retrieving observations and sensor system information. This is the intermediary between a client and an ob- servation repository or near real-time sensor channel.
5. Sensor Planning Service (SPS) – Standard web service interface for re- questing user-driven acquisitions and observations. This is the interme- diary between a client and a sensor collection management environment.
6. Sensor Alert Service (SAS) [68]– Standard web service interface for pub- lishing and subscribing to alerts from sensors.
7. Web Notification Services (WNS) – Standard web service interface for asynchronous delivery of messages or alerts from SAS and SPS web ser- vices and other elements of service workflows.
The goal of OGC SWE SOS is to provide access to observations from sensors and sensor systems in a standard way that is consistent for all sensor systems in- cluding remote, in-situ, fixed and mobile sensors. SOS standard version 1.0.0 [69] is describing the messaging system based on SensorML and TML encod- ing which invoke requests on HTTP server in REST or POX architecture style.
SOS standard version 2.0 [70] provide binding over SOAP webservice.
The key to the model on Figure2.7is that an Observation is modeled as an event which produces a result whose value is an estimate of a property of the observation target or feature of interest. An observation instance is classified by its eventTime, featureOfInterest, observedProperty, and the procedure used (often a Sensor). Note that OGC SWE SOS is not based on EDA architecture but on SOA service.
. Previous and related work
In previous work [47] we developed Websocket server Draft 76 and HTML5 client application that was sending the words to the server via Websocket and XHR and server analyzed them by morpohological analyzer. Result of anal- ysis was returned to the client. Benchmark of XHR vs. Websocket tunnel shows up to 1:180 RTT reduction for dataset with 10000 words. Today many of Websocket server implementation exists.
Ruottu and Markus created a proof-of-concept called Browser-Socket [74] that utilized WebSockets for browser-to-browser (peer-to-peer within browsers) communication. They have developed a Firefox plug-in that created a socket server.
Figure 2.7: Basic Observation structure
Table 2.3: Table of Websocket servers (servers without RFC6455 not men- tioned)
Server, version Language Version date SuperWebSocket 0.8 C#.Net Jun 4, 2013
Alchemy 2.2.1.238 C#.Net May 31, 2012 Eclipse Jetty Server 9.0.4 Java Jun 26, 2013
Tornado 3.1 Python Jun 15, 2013 Pywebsocket 0.7.9 Python May 18, 2013
Ratchet 0.2.7 Python Jun 23, 2013 sgcWebSockets 2.4 Delphi Jun 24, 2013
clws Lisp Not released yet.
Some guys at LearnBoost did an evaluation on “Socket.IO and firewall soft- ware” [41]. They have investigated 16 personal firewalls to find out how they treat WebSocket connections. Three of them blocked WebSocket connections.
For the remaining firewalls there was always a fall-back port available. Inter- estingly, some browsers were blocked even on port 80. They concluded that a move of the WebSocket traffic to port 443 fixed all connection problems.
. Informal description of Weda architectural style
. Motivation
Weda architectural style is hybrid architectural style that we have derived from other network-based styles, such as web services [39] and HTML5 web-sockets [30] to get practical real-time SOA 2.0 [59] solution for WWW. It provides uni- form connector interface to the client and server implementers allowing them to extend their existing web services (SOAP 1.2, REST, POX) with new type of endpoints and binding while keeping their HTTP server endpoints to legacy clients alongside with Weda endpoints. When such an architectural style im- plemented into API, users can get World-Wide-Web messaging and workflow orchestration ESB platform. Such a solution can improve scalability of WWW and SOA and can change interaction habits and user experience extensively.
An ontology is a data model that represents a set of concepts within a do- main and the relationships among those concepts. The semantics of WWW- based architecture ontology is defined as follows [33], [72]:
EAType⊆ Infrastructure(t) ∪ Management(t) ∪ Process(t)∪
Configuration(t)∪ Component ∪ Connector ∪ Port ∪ Role ∪ QA (3.1) in which, EAType denotes enterprise architecture type, for example Weda. Ta- ble 3.1 lists architectural ontology entities – infrastructure, management, ser- vice, service consumer and data – constrained in their relationships in order to achieve a desired set of architectural properties. It was chosen because unlike component-based approach which was used to describe a REST architectural style [32] it has ability to model dynamic behaviors.
Figure3.1 gives a high-level process view of Weda infrastructure and man- agement, while details are described in next sections.
Schema indicates number of application clients connecting to server host process as usual in client-server style. Server host process runs in standard web server, such as Apache, IIS or it can be console app as well. Figure shows how you can combine existing standards with new parts of stack, allowing the vendors to reuse their code.
At the top part of the schema new parts of infrastructure are highlighted by a wider line. Other chapters explain their details.
Table 3.1: Weda’s major architectural ontology entities Ontology
entity
Details Example
Infrastructure Service provider, Origin server, server host process
Apache httpd, IIS, web infra-structure
Management Service host, Weda gate- way, set of endpoints and channels traversable through firewalls and reverse proxies.
Weda transport binding, Weda client and server API, websocket connec- tion, session manager, weda channel,Event processor with Esper engine.
Service Object representing a set of operations for the client, IO data, message exchange patterns, tem- porarily available thru the set of endpoints to a service. In Weda there are infrastructure specific services for eventing.
SOAP 1.2 Calculator service, SOAP1.2 Weda statement, ws-eventing services, REST ser- vice, OGC SOS service, Weda’s event processing layer
Data Service contract and callback contracts, Weda messages
WSDL 2.0, Weda sub- protocol, SOAP encod- ing, XML, MTOM
Service con- sumer
Proxy stub Application client, user agent , event source or event sink
Process Discovery, Choreography Uddi
application client server host process
service host
"legacy 2" service instance per call service host
application client session B
session manager session A
EDA manager service proxies
weda endpoint, session B
service host callback service proxy instance
service proxy instance
"legacy" service proxy instance
application business layer
pox endpoint
soap endpoint
"legacy" service instance per session
"legacy" service proxy instance application client
weda endpoint, session A
wsdl resources weda endpoint,
session C session C
some async service proxies service proxy instance callback service proxy instance
async service instance per session
Event processing Services (CEP)
callback contract service contract
rest endpoint
soap/
rest/
pox
service contract
reply channel (HTTP) request channel (HTTP)
app. BL
"legacy 2" service instance per call
"legacy 2" service instance per call
"legacy 2" service instance per call
"legacy 2" service instance per call
"legacy 2" service instance per call
BL
Figure 3.1: High-level process view of Weda infrastructure
At the bottom we have a very standard web service host, which is run-time environment that creates and controls web-service’s context and instance life- time and makes it active. Inside service host there is one “legacy” service, in- stantiated per call, so a new service object is created and destroyed by each HTTP request and response. This allows using the service instance by HTTP channel, because state is not maintained between the calls giving us a stateless web service. Stateless web services should have light-weight initialization code (or none at all) that can be called from a single threaded model.
Service instance must be initialized to expose (service related) entry points for a service called endpoints (address, binding, contract). Special constraints are made to endpoints in Weda architectural style to cooperate well with trans- port channel and Weda gateway as outlined in chapter3.3.3. On the service- consumer side there are proxy stubs generated from the WSDL file. There are special options for client proxy objects and some constraints too as outlined in chapter3.5.
. Comparison of Web services architectural styles
As we said before (chapter2.2) a SOA is a design model with a deeply rooted concept of encapsulating application logic within services that interact via a common communications protocol. Such a general concept has its application in Web services architecture described earlier too. Architecture style is a class of architectures or significant architecture pieces that can be found repeatedly in practice [18].
Currently most Web services architectures adopt RPC as their architectural style and as such are based on WS-* (SOAP, WSDL, WS-Addressing, WS- ReliableMessaging,WS-Security, etc.) or as well on POX definitions. In RPC the server is looked as a set of procedures and the client calls these procedures to fulfill a task, so unconsciously it limits the way in which service consumers use these services. But there are countless business rules in actual application systems. If you wanted to cover all business rules with such procedures in services, the cost would be enormous.
REST architectural style uses resources to reach a specific object, function or something that can be treated as resource. Resource is a nominal concept, so the modeling based on REST is noun-centralized (Domain Model architectural pattern).
There can be a hybrid architetural style called REST-RPC [52] which is not much used in practice.
SOAP is often messed to be one of architectural styles. But SOAP mes- sage is formally specified as an XML Information Set (henceforth often sim- ply infoset), which provides an abstract description of its contents. One of the intended uses of SOAP intermediaries is to forward messages to different networks, often using different transport protocols. SOAP is then often used together with RPC-style. But SOAP 1.2 format can be used in a manner consis- tent with REST (however, it can also be used in a manner that is not consistent with REST).
Every style has its advantages, disadvantages or limits.
Call oriented systems (REST, RPC) are usually synchronous in nature and focus on the particular operation to be invoked, its set of input and output val- ues and correlation of replies with requests. They don’t focus on how individ- ual values are marshalled as an unit or how output values are produced from input values (we are presuming that output values are correct).
Message passing systems are usually asynchronous in nature and focus on construction of message payload in correct format, dispatching the message (transport medium and endpoint) and do not focus on what will happen to messages after are dispatched or whether there will be a corresponding reply message.
Approach of this section is to compare these existing architecture styles against proposed Weda architectural style.
So we can identify three classes of Web services:
• REST-compliant Web services, in which the primary purpose of the ser- vice is to manipulate XML representations of Web resources using a uni- form set of “stateless” operations
• RPC-compliant Web services, in which the service may expose an arbi- trary set of operations.
• WEDA-compliant Web services, in which the service can use asyn- chronous message passing which can provide us eventing behaviour as well as call & return.
In table3.2I compare attributes of identified styles. For Weda architectural style I assign references to the chapter where details can be found.
1 In future work, architecture style should be provided with better flow control (see3.7.4) mechanism as there is opportunity to perform better than REST-style as is shown on graphs of minimal response times (chapter9tables9.2,9.7,9.16,9.20 ) measured on experimental systems.
Table 3.2: Comparison of Web services architectural styles
attribute WEDA-style REST-style RPC-style
architecture SOA2.0 (event-based SOA) [2.6]
SOA [2.2] SOA
distributed system type
hybrid (message passing and call / return)
call / return call / return
addressability multiple endpoints (address, client ad- dress+identifier) per service (clients, server) (see3.3)
unique URI address per resource
one endpoint (ad- dress, contract) per service
common transport
HTML5 WebSockets (see 2.9)
HTTP HTTP
state statefull stateless stateless
flow con-
trol
asynchronous (see 3.5, 5.2.2)
synchronous synchronous (over
common transport) process
commu- nication models
one-to-one, one-to-many, many-to-many
one-to-one one-to-one
latency bad (without specific flow control mechanism) 1 or best with admission and flow control
best good
throughput best (see9) bad bad
instance context
per session (see3.5) per call per call (over com-
mon transport) scalability bad (see3.7.3) for horizon-
tal, best for vertical scal- ing, best in terms of con- current clients
good good
coupling loose (only event type definitions in duplex contracts)
functionally tightly cou- pled (MIME types in self-descriptive resource representations)
functionally tightly coupled (operations and data types in contract)
data inter- face
inherited (no restriction) (see3.3.8,5.2.4,C)
generic (e.g. HTTP verbs, MIME)
service description (e.g. WSDL)
common data format
inherited (no restriction) (see3.3.6)
HTTP resource repre- sentation, XML, JSON
SOAP deployment
topologies
enterprise service bus (see 2.7)
hub and spoke (central- ized)
hub and spoke (cen- tralized)
coordination ESB’s native functions for orchestration and choreog- raphy, no scheduler
resource-oriented work- flows (theoreticall - atom, rss, dynamic hyperlinks in practice)
service-oriented workflows, scheduler required (see2.8)
. Weda channel stack
.. Overview
The main purpose of the work is to ensure interoperability between the imple- mentations of different Web services/Weda vendors. The main audience will be the people, who wish to extend a Web services stack with an implementa- tion of Weda. This will enable them to write a Weda implementation that will interoperate with other independent Weda implementations. The chapter will also be of the interest to providers of Web services intermediary. We do not discuss any details of how such intermediary may be designed or configured.
Channel stack is a layered communication stack with one or more channels that process messages. At the bottom of the stack is a transport channel that is responsible for adoption to the underlying transport. Weda architecture builds upon the duplex web socket connection. Next sections describe a binding mechanism and outline some considerations about it.
Note that MAY, SHOULD, MUST, SHOULD NOT, MUST NOT terms (in all caps) are used as described in [10]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT. Such a description can easily be used as RFC draft in future.
.. Weda gateway
Weda gateway (Fig.3.2) is important required component in the architecture style. Unlike message-oriented middleware, a Webservice/Weda system can run without a dedicated message broker, which results to better latencies and easier administration and cost. Weda gateway should be an intelligent messag- ing library, suited for use with web services over the WebSocket connection and adding new possibilities to EDA interactions over the public internet. The defining features of Weda gateway are message orientation, queuing, routing (including publish-and-subscribe). We know, that is unusually ambitious in going from very low level (data on the wire) to very high level (application semantics), in a single leap, but that’s what is Weda architectural style about at all. We need such wideness to make things begin to function. You can find some assimilation to binary protocol standard AMQP [67], but instead of be- ing so much multifunctional (and dangerously complex) and standalone solu- tion, Weda gateway has other goals to achieve. When implemented, it should provide an easy-to-reference API for use in web or desktop applications and should be easily pluggable into the existing stack.
At the application start, the Weda gateway MUST be bootstrapped. It’s main responsibility is to configure and run WebSocket server, so the frames be- come accessible by the implementation of WebSocket API called here as “wire listener” component and transformed into messages. Wire listener MUST deal with the WebSocket framing issues. Some considerations about this are men- tioned in the section3.3.9.
