Service Oriented Computing and Applications manuscript No. (will be inserted by the editor)

Technologies for Web and cloud service interaction: a survey

Harald Lampesberger

Received: date / Accepted: date

Abstract The evolution of Web and service technologies 1 Introduction has led to a wide landscape of standards and protocols for interaction between loosely coupled components. The need to share network-based resources and use remote Examples range from Web applications, mashups, apps, and functionality in a program without dealing with low-level mobile devices to enterprise-grade services. Cloud comput- network access has fueled discussions in the 1970s [263, ing is the industrialization of service provision and deliv- 290,369] and ultimately led to the ery, where Web and enterprise services are converging on (RPC) framework by Birrell and Nelson [37] in the 1980s. a technological level. The article discusses this technologi- RPC became a driver in enterprise systems; location trans- cal landscape and, in particular, current trends with respect parency of procedures eases code reuse but requires tight to . The survey focuses on the communi- coupling, e.g., a unified type system. In the 1990s, the prin- cation aspect of interaction by reviewing languages, proto- ciples of object orientation and RPC gave raise to distributed cols, and architectures that drive today’s standards and soft- objects [222]. Tight coupling and interaction complexity in ware implementations applicable in clouds. Technological RPC and distributed objects affected the scalability of enter- advances will affect both client side and service side. There prise systems, and at the end of the 1990s, is a trend toward multiplexing, multihoming, and encryption between so-called services became an alternative enterprise in upcoming transport mechanisms, especially for architec- architecture with relaxed coupling and easier scalability. To- tures, where a client simultaneously sends a large number of day, middleware for message queuing and the concept of requests to some service. Furthermore, there are emerging service-oriented architecture (SOA) [212] dominate large- client-to-client communication capabilities in Web clients scale distributed enterprise systems. that could establish a foundation for upcoming Web-based messaging architectures. In the meantime, Berners-Lee [360] laid out the foun- dation for a of nonlinear text documents, i.e., hypertext, exchanged in a client-server architecture over Keywords Web technology · Web services · Cloud arXiv:1408.2751v3 [cs.NI] 9 Mar 2015 the predecessor of today’s in 1989. The first Web services · Service architecture · Communication protocols · browser was announced end of 1990, the World Wide Web Languages · Service interaction patterns Consortium (W3C) was established in 1994, and W3C pub- lished the first Hypertext Markup Language (HTML) Rec- ommendation in 1997. Since then, the Web has evolved from H. Lampesberger Christian Doppler Laboratory for Client-Centric Cloud Computing, simple exchange, to interactive user interfaces, Johannes University Linz, rich client applications, user-provided content, mashups, so- Softwarepark 21, 4232 Hagenberg, Austria cial platforms, and wide-scale mobile device support. Web E-mail: [email protected] technology has become pervasive and is not limited to hy- This is the author’s accepted draft. Please cite the published ver- permedia applications anymore. Standards are widely ac- sion: Lampesberger, H.: Technologies for Web and cloud service cepted, and they have contributed to the success of Web ser- interaction: a survey. Service Oriented Computing and Applications vices because protocols like the Hypertext Transfer Protocol (2015). DOI 10.1007/s11761-015-0174-1 (HTTP) are reliably forwarded over the Internet [4,253]. 2 Harald Lampesberger

Cloud computing [24] can be seen as the industrializa- Service Interaction Pattern Section3 tion of service provision and delivery over the Internet using established technologies from the Web [90] and from en- terprise services [35]. The goal is to offer a service, acces- Protocol Architecture sible across devices, systems, and platforms. Interaction by communication between service consumers and providers, Language Implementation i.e., clients and services, is therefore a key aspect of service Section4 Section2 Section5 delivery. Cloud service delivery models like Platform-as-a- Service (PaaS) or Software-as-a-Service (SaaS) benefit from well-known and their wide acceptance [24, Fig. 1 The concepts and their relationships found in communication technologies also reflect in the structure of the survey 90,292]. To acknowledge this relation between Web and ser- vices technology, this article surveys the state-of-the-art and recent trends in technologies applicable in clouds. munication technologies applicable to the Web, PaaS, and SaaS are surveyed.

1.1 Scope 1.2 Motivation A survey of technologies in such a dynamic environment needs a defined scope. All technologies that allow a client This survey is motivated by ongoing research efforts in for- to interact with a service should be considered; however, the mal modeling of cloud services [48,44,292], modeling of notion of service is not precisely defined [292]. The follow- service quality [269,268], service adaptation [56], identity ing informal properties and restrictions therefore character- management [326,325], and security monitoring [159,158, ize a service in context of this work: 160] for cloud services. All these aspects need communica- tion between clients and services. Understanding the state- – Service interface. Services are considered as distributed, of-the-art in service communication is therefore necessary, network-accessible software components that offer func- e.g., for security research because an ambiguous or impre- tionality and need communication for interaction [107, cise service interface is in fact a gateway for attacks [288]. 253]. A notion of interface that accepts a certain lan- There is a rich body of literature using patterns to de- guage is therefore required. The survey is restricted to scribe service interaction on a conceptual level [1,26,25, technologies that enable communication between clients 118,378]. On the other hand, the numerous software imple- and service interfaces applicable in Web, PaaS, and SaaS mentations used in today’s services are heavily driven by cloud delivery models. continuously evolving standards and ad hoc specifications. – Heterogeneous platforms. A characteristic of service- This work aims to bridge this gap by surveying the state-of- orientation is to provide functionality and content across the-art of technologies and resort to patterns when concepts hard- and software platforms. Only technologies that em- are discussed. Patterns are appealing because they allow to brace this compatibility are considered. describe solutions in a conceptual way and can therefore – Publicly available standards. The focus is on technolo- support service integrators and scientists in understanding gies that are available to the public audience, in partic- new technologies. ular, technologies based on Internet protocols, i.e., the TCP/IP protocol suite [302], and with publicly available specifications. Specialized technologies for a limited au- 1.3 Methodology and structure dience or application, like industrial control systems, are not part of this study. The problem is approached both in top-down and bottom- – Parties. There are two participating parties or peers in up manners. In the top-down view, entities of information service interaction: a client that consumes some service are exchanged between peers, i.e., clients and services, in an offered by a provider or server, i.e., client-to-service in- agreed-upon style, i.e., interaction pattern. The article there- teraction. On a conceptual level, a service can participate fore discusses languages for encapsulation information, so also as a client to consume other services for a compo- information becomes transportable. The bottom-up view in- sition, i.e., service-to-service interaction. Furthermore, a vestigates how an agreed-upon style of interaction is actu- service can coordinate two clients to establish client-to- ally implemented in today’s networks, i.e., communication client or peer-to-peer interaction. protocols and architectures for information exchange. Fig. 1 visualizes the relationships between concepts required for In accordance with the aforementioned characteristics, service interaction. The relations and concepts have been de- the state-of-the-art and recent trends in Web and service com- rived from the extensive literature review in this article. Technologies for Web and cloud service interaction: a survey 3

Languages are fundamental for communication. A lan- by nonprofit organizations, communities, consortia but also guage defines an , syntax, and semantics to repre- enterprises. Important institutions are therefore recalled. sent information in a transportable format. Languages there- To develop industrial standards on a global scale such fore encode content, media, and information in general. Pop- as specifications for electronic communication devices, e.g., ular languages in the Web and for services are discussed in networking, the International Organization for Standardiza- Sect.2. tion (ISO) [132], the International Electrotechnical Com- Due to the many styles of interaction, conceptual pat- mission (IEC) [131], and the International Telecommunica- terns for a unified nomenclature are considered, in particu- tion Union (ITU) [133] are three connected organizations lar, service interaction patterns (Sect.3) introduced by Bar- that closely work together. The Institute of Electrical and ros et al. [25,26] in context of the Workflow Patterns Ini- Electronics Engineers (IEEE) Standards Association [130] tiative [372]. These patterns are rather informal but man- is also well known for global networking standards, e.g., the ageable in their number and sufficiently abstract to discuss IEEE 802.3 standard. and compare interaction in the survey. The relations between With respect to language and protocol specifications, the patterns, protocols, and architectures are bidirectional from Internet Engineering Task Force (IETF) [136] organizes a a historic point of view; patterns have been derived from community process to develop standards, especially com- successful protocols, and patterns have influenced the spec- munication protocols, through open ification of new protocols. (RFCs). The W3C [373] drives Web standardization efforts, A communication protocol specifies a language for a and the Object Management Group (OMG) [226] aims for communication channel and rules of engagement to imple- standardized business process modeling. Another nonprofit ment a certain interaction pattern. Protocols can integrate organization for developing open standards for languages other protocols to become a , as common in and protocols, specifically for enterprise services, is the Or- Internet protocols, with the self-reference in Fig.1 repre- ganization for the Advancement of Structured Information senting this relation. Relevant protocols for Web and cloud Standards (OASIS) [241]. services are surveyed in Sect.4. The Internet Corporation for Assigned Names and Num- To deliver a service, an architecture specifies communi- bers (ICANN) [135], including its department Internet As- cation protocols for low-level interaction, languages for en- signed Numbers Authority (IANA) [134], is a nonprofit or- coding information, and high-level interaction patterns be- ganization for directing worldwide the agreement on Inter- tween peers. Architectures are basically blueprints for avail- net addresses, domain names, and protocol identifiers. Also, able transport mechanisms and formats, and Sect.5 inves- a number of standards have been proclaimed by enterprises tigates architectures found in the Web and services appli- that use them internally or offer them as software or services, cable to cloud computing. Architectures are eventually im- e.g., Amazon, Cisco Systems, , Facebook, IBM, Mi- plemented as executable software, and popular implemen- crosoft, and Oracle. tations are discussed when appropriate. Scientific findings, observations, and potential implications are then discussed in Sect.6, whereas Sect.7 concludes the survey. 2 Languages for content and media The survey investigates text-based, binary, and container formats for information encoding; protocols in terms of the Formally, a language is a (possibly infinite) set of strings TCP/IP protocol stack, including multiplexing and multi- generated from a finite set of symbols, referred to as alpha- homing transport mechanisms, HTTP extensions, and wire bet [119]. Languages are essential to communicate informa- formats for messaging protocols; and architectures in a Web- tion represented as . While information exchange oriented view (Web applications, Web syndication, and Web in Web and cloud services can be distinguished into message mashups) and a service-oriented view (RPC, Web services, and stream based, a stream is in fact a single message sent and messaging solutions). The contribution of this article is in chunks or as a sequence of individual smaller messages. a discussion of cloud aspects and cloud-specific develop- Languages for encoding content or media are also referred ments; multiplexing, multihoming, and encryption in mod- to as data formats or formats in short. ern transport mechanisms; correctness of content types; up- Communicating parties can only parse content of a cer- coming client-to-client capabilities; and the impact on net- tain kind, where the format, i.e., syntax, and meaning, i.e., work traffic monitoring. semantics, of the language are defined. The hardness of pars- ing is then a computational complexity property of the lan- 1.4 Standardization bodies guage [111]: With increased expressiveness, more and more information can be encoded in a language, but parsing also Standards for languages, protocols, and architectures in the becomes harder and therefore more error-prone in software Internet, in the Web, and for services are primarily driven implementations [288]. 4 Harald Lampesberger

Alphabets for intercommunicating digital systems are typically binary, and the basic unit of information is a bit. For Internet applications, a byte of eight bits is a common Hello World transferable unit. Content can be distinguished into binary and text based with respect to the alphabet:

Headline

A sample paragraph.

– Binary content. When a language describes a bijection between digital sequences and the domain of actual val- ues and structures, then contents are referred to as binary content and they are likely not human-readable. – Text-based content. Text is not simply text, but rather Fig. 2 A minimal example for HTML5 has the characteristic document type declaration and a html root tag bits and bytes with an associated mapping to human- readable symbols, so some digital sequence has a tex- tual representation. Such a mapping is called character on human-readable encodings has contributed the success encoding or character set, e.g., ASCII. Content is said to of hypermedia. be text based, if its syntax has a human-readable repre- sentation. 2.2.1 Semi-structured languages ASCII is the most fundamental character encoding; it uses seven bits to enumerate a set of control and printable Three of the most influential languages for information ex- characters, but it is limited to the English alphabet. Uni- change in the Web are HTML, the Extensible Markup Lan- code [322] attempts to enumerate all the human-readable guage (XML), and the JavaScript Object Notation (JSON). symbols in all natural languages. Character encodings like the ASCII-compatible UTF-8 [377] then specify a compact, Hypertext Markup Language. HTML is the standard for byte-oriented encoding to represent millions of symbols ef- defining and has the MIME type text/html. It ficiently. uses markup such as tags, attributes, declarations, or pro- cessing instructions to express structural, presentational, and semantic information as text. While earlier HTML versions 2.1 Content types up to 4.01 [330] are an application of the Standard General- ized Markup Language (SGML), which requires a complex Formally, a type is a general concept shared by a set of ob- SGML parser framework, today’s HTML5 [363] specifies jects, also referred to as the instances of a type. With respect an individual parser. to content and media, a content type is then an identifier that An examplary HTML5 document is listed in Fig.2. specifies the alphabet, character encoding, syntax, and even- SGML-based parsers distinguish the grammars of different tually semantics of a language. The notion of content type is HTML versions in the document type declaration in the first essential for modular software design, where an appropriate line. As HTML5 is not SGML based, the document type parser is chosen during runtime based on the content type. declaration is deliberately incomplete to indicate SGML in- In today’s applications, the Multipurpose Internet Mail dependence. A document is separated into a header for Extensions (MIME) have become an Internet standard for and a body for the semi-structured content of a specifying content types in the Web [92]. They are referred . All allowed tags are specified in the standard. In- to as MIME content type, Internet media type, or MIME type terestingly, the character encoding of a document is defined for short. For example, the MIME type of a simple ASCII within the document itself in a meta tag. This tag should be text is text/plain. A MIME type identifier can also ex- the fist tag in the header, so the parser becomes aware of the plicitly refer to the character encoding of text-based contents encoding before other tags are encountered. [175], e.g., text/plain; charset=utf-8. An SGML or HTML5 parser in a trans- forms a document into a (DOM) 2.2 Text-based content [335], a generalized tree-like data structure that is eventually rendered visible by the . Another popular for- Compared to binary formats, text-based languages have a mat with respect to HTML is Cascading Style Sheets (CSS) lower information density because human-readable symbols [349] for defining both the look and behavior of a DOM’s need to be digitally encoded. For example, an integer num- visual representation. ber n > 0 needs dlog10 ne bytes in UTF-8 encoding, while ef- ficient binary representation requires only dlog2 ne bits. De- Extensible Markup Language. XML [346] originates from spite lower information density, the worldwide agreement SGML, but it is more restricted and popular for electronic Technologies for Web and cloud service interaction: a survey 5

{ " movie ": { "year": 1968, 2001: A Space Odyssey "title": "2001: A Space Odyssey", S. Kubrick "director": {"nid": "nm0040", "n": "S. Kubrick"}, A good movie. " review ": [ {"text": "A good movie", "public": true}, {"text": "Complex", "public": false} ], Fig. 3 An exemplary XML document with mixed-content [158] "prequel": null } }

Fig. 4 A JSON document that applies all available basic datatypes and . An example is shown in Fig.3. Tags, at- has a length of 248 bytes in UTF-8 encoding tributes, namespaces, declarations, and processing instruc- tions are syntactic constructs for structuring information in an XML subtype with a strict syntax specified in a schema, XML as text. The first line in an XML document should so an XML parser can be used instead of a complex markup be a processing instruction that informs the parser about the parser. XML is also the supertype for many Web formats, XML version and the applied character encoding. e.g., (SVG) [350] or Mathemat- XML is a language family: The structuring of elements ical Markup Language (MathML) [334], and MIME types (tag names) and attributes within a document is unrestricted, for well-known subtypes are specified in RFC 3023 [197]. and only the syntactic rules have to be obliged. Element con- tent is limited to text; by default, XML distinguishes two JavaScript Object Notation. JSON [47] is a simple text for- datatypes, parsed (PCDATA) and unparsed character data mat to serialize information as structured key-value pairs. (CDATA). Mixed-content XML relaxes element content re- JSON has the MIME type application/, and it is strictions; text in element content is also allowed to nest human-readable, as shown in Fig.4. The syntax is a sub- other elements, e.g., the review element in Fig.3. set of the JavaScript language (discussed in Sect. 2.5), and The underlying logical structure of XML is a tree; there- a JSON document is either parsed or evaluated to an object fore, open and close tags must be correctly nested. A docu- during runtime. JSON specifies six basic datatypes: null, ment with correct nesting, proper syntax, and a single root Number, String, Boolean, Array, and Object, and syn- element is well-formed. Furthermore, a document is said to tactic rules to represent them as text. A proper JSON docu- have an XML Information Set [339] if it is well-formed and ment always has a single root object. namespace constraints are satisfied. An Infoset is an unam- Similar to XML, JSON defines a family of languages biguous abstraction from textual syntax; e.g., there are two because there are syntactical restrictions, but no structural syntactic notions for empty elements in plain XML. limitations in the standard. JSON Schema [95] is a schema To restrict the structure, XML offers schema languages, language expressed in JSON format, and the motivation is e.g., Document Type Definition (DTD) [346], XML Schema the same as in XML schemas: to define a set of JSON docu- (XSD) [340], and Relax NG [201]. Formally, a schema is a ments and enable schema validation. grammar that characterizes a set of XML documents, and a document is said to be valid if its schema is obeyed [172]. In 2.2.2 Binary-to-text encodings this sense, a schema allows to specify a content subtype of XML. XSD and Relax NG also support more fine-grained Base16, , [148], Percent-Encoding [34], and datatypes than PCDATA and CDATA for restricting element Quoted-Printable [91] are binary-to-text encoding schemes contents. to map an arbitrary binary value to a text of ASCII print- The duality of text representation and logical tree struc- able characters. Most notably, Base64 encoding is a popular ture of documents has led to two different processing ap- method to embed arbitrary binary content in XML or JSON proaches. A document can be either parsed into a DOM as text, but incurs a 33% overhead due to reduced informa- for tree operations or processed directly as a stream of text, tion density. open-, or close-tag events using the Simple API for XML (SAX) [289]. 2.2.3 Other text-based formats Repeated element names in tags reduce the information density in XML. SXML [154] is an alternative syntax using There exist several specifications for text-based languages S-expressions such that element names occur only once, and with varying popularity, for example, comma-separated val- higher information density is achieved. ues (CSV) [294] for relational data; markup languages Can- The MIME media type of the XML language family is dle [51] and YAML [31]; the Ordered Graph Data Language application/. XHTML [333] is a re-specification of (OGDL) [323] for graph-structured data; and the Open Data HTML and has a MIME type that indicates the XML ori- Description Language (OpenDDL) [163] for structured in- gin (application/+xml). XHTML is conceptually formation. 6 Harald Lampesberger

81 a5 6d 6f 76 69 65 85 a4 79 65 61 72 cd 07 b0 a5 74 Content-Type: multipart/mixed; boundary="endpart" 69 74 6c 65 b5 32 30 30 31 3a 20 41 20 53 70 61 63 65 20 4f 64 79 73 73 65 79 a8 64 69 72 65 63 74 6f 72 82 Data in this section is undefined. a3 6e 69 64 a6 6e 6d 30 30 34 30 a1 6e aa 53 2e 20 4b -- endpart 75 62 72 69 63 6b a6 72 65 76 69 65 77 92 82 a4 74 65 Content-Type: text/plain; charset=utf-8 78 74 ac 41 20 67 6f 6f 64 20 6d 6f 76 69 65 a6 70 75 62 6c 69 63 c3 82 a4 74 65 78 74 a7 43 6f 6d 70 6c 65 This first part is UTF-8 encoded text. 78 a6 70 75 62 6c 69 63 c2 a7 70 72 65 71 75 65 6c c0 -- endpart Content-Type: image/gif Content-Transfer-Encoding: base64 Fig. 5 A MessagePack equivalent of the JSON document in Fig.4. The binary representation in notation reduces the length R0lGODlhAQABAIAAAAUEBAAAACwAAAAAAQABAAACAkQBADs= --endpart-- to 144 bytes [94]

Fig. 6 This text-based MIME multipart/mixed container example 2.3 Binary content has two parts and demonstrates the boundary principle

Binary formats offer compact representation of information text-based header that denotes its Content-Type and addi- but are are typically not human-readable, e.g., audio and tional metadata such as binary-to-text or transfer encodings. video formats. Abstract Syntax Notation One (ASN.1) [70] Multipart defines several subtypes: is a popular standard for structured information exchange. ASN.1 distinguishes between an abstract specification of in- – multipart/alternative [92] to model a choice over formation structure and encoding rules such as Basic Encod- multiple contents to a consumer; ing Rules (BER) or Distinguished Encoding Rules (DER). – multipart/byteranges [76] to encapsulate a subse- An encoding rule defines how an actual instance, according quence of bytes that belongs to a larger message or file; to some abstract structure, translates to bits and bytes. An – multipart/digest [92] to store a sequence of text- application of ASN.1 using DER are X.509 certificates in based messages; today’s public key infrastructures [273]. – multipart/form-data [173] for submitting a set of As text-based languages incur overhead, binary equiv- completed form fields from an HTML website; alents to popular text-based formats have been proposed. – multipart/message [92] for an email message; With respect to XML, binary representations are: Efficient – multipart/mixed for inline placement of media in a XML Interchange (EXI) [362]; .NET Binary XML [184]; text-based message, e.g., embedded images in emails; Fast Infoset [141] as an application of ASN.1; and Binary – multipart/parallel [92] to process all parts simul- MPEG Format for XML (BiM) [139], which originates from taneously on hardware or software capable of doing so; a video format. – multipart/related [165] as a mechanism to aggre- There are also attempts to optimize JSON representation gate related objects in a single content; through binary equivalents, e.g., Binary JSON [49], Mes- – multipart/report [157] as a container for email mes- sagePack [94], and Concise Binary Object Representation sages; and (CBOR) [43]. Fig.5 gives an example, how MessagePack – multipart/x-mixed-replace [199] for a stream of translates the JSON document from Fig.4 into a more com- parts, where the most recent part always invalidates all pact form. preceding ones, e.g., an event stream. Some RPC architectures (Sect. 5.2.1) specify binary for- mats to serialize data, e.g., External Data Representation An application of multipart is XML-binary Optimized (XDR) [188], [13], Apache [11], Apache Packaging (XOP) [347]. XOP specifies a container format Thrift [10], [99], and Hessian [54]. Other for XML as a MIME multipart/related package [165], binary languages worth mentioning are the Structured Data where binary element content is directly embedded to re- Exchange Format (SDXF) [371] for hierarchical structures, move the necessity of binary-to-text encoding. The W3C and [18], a data serialization format in Apple specifies a set of attributes and rules for XML and XSD systems. to handle MIME types [341] which are effectively used in XOP. S/MIME [270] is a security extension for MIME. It de- 2.4 Container formats fines encryption (multipart/encrypted) and digital sig- natures (multipart/signed) for confidentiality, integrity, A container is an encoding to encapsulate other arbitrary and non-repudiation of data using public key cryptography. contents. The MIME standards specify a multipart [92] con- In general, a drawback of MIME multipart is that the tent type for containers, where contents of varying types are boundary string must not appear in any of the parts because interleaved. In multipart, a text-based boundary string sep- it would break the format. Microsoft’s Direct Internet Mes- arates individual parts as shown in Fig.6. Each part has a sage Encapsulation (DIME) [181] is another standard for Technologies for Web and cloud service interaction: a survey 7

Send of participating parties; the number of message transmis- Single-Transmission Receive sions in an interaction; and whether messages in two-way Bilateral Send-Receive interaction are routed to third-parties or take round trips. This leads to four pattern groups: single-transmission bi- Racing Incoming Messages lateral, single-transmission multilateral, multi-transmission, One-to-Many Send Single-Transmission and patterns. This section is a high-level summary Multilateral One-from-Many Receive Service of the original descriptions [26]. Interaction One-to-Many Send-Receive Patterns Multi-Responses

Multi-Transmission Contingent Requests Atomic Notification 3.1 Single-transmission bilateral patterns Request with Referral Routing Pattern Relayed Request Send. Party A sends party B a message. Dynamic Routing Related to: unicast, point-to-point send. Receive. Party A awaits an incoming message. Fig. 7 The service interaction patterns by Barros et al. [25,26] charac- Related to: listener, event handler. terize message-based interaction between two or more parties Send-Receive. Party A sends party B a message and causes B to respond with a message. This pattern has a dual, encapsulation and streaming of arbitrary binary data in the i.e., Receive-Send, where party A waits for an incoming spirit of MIME multipart, but with an improved boundary message and returns a response when received. mechanism to reliably distinguish parts. Related to: request-response, request-reply, RPC.

2.5 JavaScript 3.2 Single-transmission multilateral patterns ECMAScript [72], better known as JavaScript, is a dynamic which is supported by practically all Racing Incoming Messages. Party A waits for a single in- available Web browsers today. JavaScript can be regarded as coming message from a number of possible messages text-based syntax and a JavaScript runtime environment. A and senders. The continuation of A after receiving the runtime environment is typically present in a Web browser first message depends on the message type or sender, but also available for services, e.g., Node.js [149]. and subsequent messages may or may not be discarded. JavaScript code is either embedded directly into HTML Related to: racing messages, deferred choice. or XHTML markup using script tags, inlined in attributes, One-to-Many Send. Party A sends n messages to the parties or exchanged as text-based content. When exchanged as re- B1 ...Bn, where all messages have the same type but not source, JavaScript code has an individual MIME type, i.e., necessarily the same content. application/ [117]. A browser runtime en- Related to: multicast, broadcast (where a virtual broker vironment then interprets the code to dynamically adapt the addresses all parties in the domain), event notification, DOM and its visual representation. While JavaScript is in scatter, publish-subscribe, fan-out. fact a Turing-complete programming language, its runtime One-from-Many Receive. Party A awaits a number of log- environment enforces restrictions on system and network ac- ically connected messages from senders B1 ...Bn. The cess during execution, e.g., local file access, to enforce a se- messages have to arrive within a certain time span so curity policy. they can be linked together. Related to: event aggregation, gather, fan-in. One-to-Many Send-Receive. Party A sends n request mes- 3 Service interaction patterns sages to recipients B1 ...Bn and waits for a certain time span for responses from the recipients. Whether A con- Clients and services exchange messages of certain content siders the interaction successful or not depends on the types in an interaction. The service interaction patterns in- response messages arriving in time. This pattern has also troduced by Barros, Dumas, and Ter Hofstede [25,26] are a dual, i.e., One-from-Many Receive-Send, where party recalled in Fig.7. They characterize styles of message ex- A waits for a certain time for messages from B1 ...Bn, change between parties in a distributed network and pro- then processes them and returns individual responses. pose three dimensions to distinguish patterns: the number Related to: scatter-gather. 8 Harald Lampesberger

3.3 Multi-transmission patterns Content & Media Multi-Responses. Party A sends a request to party B. B then Data Serialization returns responses until some stop-condition is met. Pos- WebRTC CoAP MQTT sible stop-conditions are an explicit notification from A, WebSocket RTPS AMQP a deadline given by A, an interval of inactivity, or an ex- Application plicit notification from B that the stream has stopped. SPDY SMTP STOMP DNS HTTP FTP XMPP Related to: streamed responses, message stream. Transport Contingent Requests. Party A sends a request message to Optional Security: SSL, TLS, DTLS B1. If there is no response within a certain time, A sends Internet MPTCP QUIC UDP Lite DCCP the request to B , and if there is again a timeout, A con- 2 TCP SCTP UDP RUDP tinues this cycle until some Bi responds properly. Link Related to: send with failover. IP, IPv6 Atomic Multicast Notification. Party A sends notifications to parties B1 ...Bn, where a minimum number of i and a Fig. 8 The Internet model [46] to the left indicates four conceptual maximum number of j recipients are required to accept layers, and the right side gives an overview of the discussed protocols the notification. A constraint of i = j = n means that all recipients have to accept. Related to: transactional notification. multiple parallel dialogs over a single channel between two peers instead of establishing multiple channels. This survey approaches the state-of-the-art for bilateral and multilateral 3.4 Routing patterns information exchange in a bottom-up fashion. Fig.8 recalls the Internet model and a number of communication proto- Request with Referral. Party A sends a request to party B, cols popular in cloud computing. Protocols in the where the message is evaluated, and based on certain specify how physically connected devices can exchange in- conditions, e.g., message content, follow-up responses formation, e.g., IEEE 802.3 Ethernet or IEEE 802.11 Wi-Fi are forwarded to a single or multiple parties ...C . 1 n networks. Related to: reply to. Relayed Request. Party A sends a request to party B, and B The Internet layer allows hosts to communicate beyond their local neighborhood of physically connected devices. relays it to parties C1 ...Cn, who take on further interac- tion with A. Party B still retains a view of the ongoing Logical addresses, routing, and packet-based data exchange are the core aspects of today’s Internet. interaction between A and C1 ...Cn. Related to: delegation. The enables inter-process communica- Dynamic Routing. There exist routing conditions that de- tion over networks. Multiple processes can run on the same fine how a message from party A is forwarded. A rout- and share the same logical network address. Transport ing condition can be dynamic, i.e., depend on content. layer protocols extend the logical addressing to enable com- Based on the conditions, a request from A is forwarded munication between distributed processes. to one or more parties B ...B that process and eventu- 1 n protocols dictate how to provide func- ally forward the message to C ...C . These parties then 1 n tionality, content, and media across two or more processes again process, continue to apply routing conditions and that are able to communicate, e.g., clients and services. Such so on. protocols provide transport mechanisms for communicating Related to: routing slip, content-based routing. messages between processes. While the Internet and Transport layer protocols are typ- 4 Protocols ically handled by operating systems, application layer pro- tocols are implemented by the client and service. From a To deal with the complexity of communication in computer lexical point of view, all Internet protocols share the same networks, layered protocol design, as proposed by the OSI binary alphabet, and a byte is typically the smallest transfer- reference model [383] or the simplified Internet model [46], able symbol. A common practice seen in Internet protocols has become an industry standard to separate concerns in is to separate a transferable sequence of bytes into a protocol communication protocol design. header and payload, where the header defines the payload Low delay and multiplexing are two major drivers for type, so other protocols can be recursively embedded. Due recent developments in accelerating Web technology. Mul- to the shared alphabet, every protocol needs an unambigu- tiplexing in this context refers to techniques for transporting ous language to prevent confusion [288]. Technologies for Web and cloud service interaction: a survey 9

4.1 Internet layer protocols – Uni- or bidirectional communication; – Connection-oriented (stateful) or stateless; The TCP/IP protocol suite [302] is the de facto standard for – Message- or byte-stream-based information exchange; computer networks. Internet layer functionality is provided – Ordering of messages or bytes in a stream; by the (IP) [260], or IPv4, which defines – Reliable delivery; packet-based networking by an addressing schema, packet – Data integrity; layouts, and routing conditions. Using IP, host A can send a – Flow and link congestion control. packet to the logical address of host B without knowing the physical address or location of B. Based on the addresses The more properties a protocol supports, the more over- in the header of the packet, so-called routers forward the head for control structures is required, and timeliness is af- packet, but delivery is not always guaranteed. IP therefore fected. This leads to an upper bound for the maximum trans- implements a Dynamic Routing pattern. To send and re- fer rate because there is always a time delay between send- ceive packets, a host needs at least one logical IP address ing and receiving information. If, for example, a protocol re- in a physically connected network, and a router (gateway) quires several interactions to synchronize state or acknowl- in this network that forwards packets. If a host is simulta- edge delivery, the delays accumulate and effectively limit neously connected to two or more physical networks, it is the available transfer rate. referred to as multihoming. The two most prominent transport layer protocols in the The maximum size of an IP packet is bounded by the Internet are the Transmission Control Protocol (TCP) [261] underlying link layer technology, and packets are eventually and User Protocol (UDP) [259]. Both protocols fragmented or dropped if they are too large. IP Fragmenta- are provided in modern operating systems. There is an in- tion allows to split oversized packets into smaller ones, but creased interest in enhanced protocols, such as MultiPath increases the load on a link because more packets introduce TCP (MPTCP) [87], Stream Control Transmission Proto- a larger overhead. The header of an IP packet specifies the col (SCTP) [303], and Google’s Quick UDP Internet Con- type of the enclosed transport protocol in the content. nections (QUIC) [277] to overcome limitations of TCP and IP has restrictions; the upper bound of 232 logical ad- UDP. dresses is the biggest issue. An ad hoc solution is Network Transmission Control Protocol. TCP is a protocol to con- Address Translation (NAT) by routers for private networks. nect two endpoints, i.e., processes, and information is ex- There is an ongoing effort to switch to IP Version 6 (IPv6) changed in bidirectional byte streams, where the correct- [67] that provides 2128 logical addresses to deal with the ex- ness and order of bytes is guaranteed. For compatibility with haustion problem that becomes immanent in an Internet of packet-based networks, a byte stream is split into TCP seg- Things. ments. A TCP connection is stateful and establishes a ses- For addressing multiple recipients with a single packet, sion between the two endpoints. It requires a so-called three- IP offers broadcast addresses based on the logical address- way handshake to synchronize, which causes a delay before ing scheme, i.e., a subnet. IPv6 does not support broadcasts. the streams can start. TCP distinguishes a client that initi- Both IP and IPv6 offer multicast, where a packet, sent to a ates the handshake, and a server that listens for incoming special logical group address, is replicated for all recipients connections. An attempt to reduce the latency caused by the in the group. Both multicast and broadcast enable the One- handshake between two already familiar endpoints is TCP to-Many Send pattern on top of Dynamic Routing. Fast Open [57]. Ideally, the Internet layer promotes content neutrality. The source and destination port number in TCP segment All routing decisions should depend on the header of IP headers identify the client and service endpoints. There is packets independent from their content. But this neutral- no payload-type identifier in TCP, and it just transfers byte ity is violated in practice. Network devices like firewalls, streams. IANA [134] therefore maintains a list of default Quality-of-Service traffic shapers, or content-based routers server listening ports that are automatically assumed by URI derive routing decisions from payloads of IP packets. Such schemes if not explicitly overridden, e.g., port 80/TCP for devices have functionality across layers in reference mod- HTTP. els, and they are referred to as middleboxes [52]. Their tech- Reliable delivery in TCP is achieved by acknowledg- niques are referred to as Deep Packet Inspection (DPI) [32]. ments and retransmissions. Integrity is guaranteed by check- sums. Segment headers also contain a window size that in- 4.2 Transport layer protocols forms the receiver how many bytes the sender can handle in the other directional stream. The window mechanism en- Transport layer protocols provide content-neutral means of ables flow and congestion control through rate adaptation. inter-process communication over networks. Protocols can The is announced as a TCP option be distinguished by certain characteristics like: to avoid IP fragmentation. A problem in TCP is the so-called 10 Harald Lampesberger head-of-line blocking; if a single byte in a stream is incor- SCTP [303] is an alternative to TCP that was designed rect or lost, the stream cannot proceed until retransmission to raise availability through multihoming as seen in MPTCP. succeeds. This imposes a problem for messaging protocols An association between two endpoints is established in a implemented on top of TCP. The necessity of acknowledg- four-way handshake. A handshake needs more interactions ments limits TCP to bilateral Send and Receive communi- than in TCP, but the SCTP service endpoint stays stateless cation. until synchronization is completed. This eliminates the well- known security vulnerability of TCP SYN flooding [73]. . UDP is a message-oriented uni- SCTP is message-based and multiplexes byte-streamed directional protocol that transports without ac- messages, similar to MPTCP subflows, in a single associ- knowledgments or order. A datagram header holds a source ation. SCTP offers reliability through checksums, optional and destination port, the payload length, and a checksum for ordering, and rate adaption for flow and congestion control integrity, and there is no support for flow and congestion [229]. Messages are sequences of bytes, and like TCP and control. The overhead of UDP is small and it is stateless; UDP, SCTP does not identify the payload type. Default lis- therefore, no synchronization is required beforehand. If the tening server ports are managed by IANA. A drawback of size of a datagram exceeds the maximum payload of the IP SCTP is its limited popularity: Transportation over the In- packet, fragmentation takes place. Similar to TCP, a data- ternet is not guaranteed because middleboxes might block gram is a sequence of bytes, and the payload type is not it. The supported interaction patterns are Send and Receive. identified. IANA also assigns default server ports to UDP- based protocols. Quick UDP Internet Connections. Developed by Google UDP supports the Send and Receive pattern without de- and already available in the Chrome browser, QUIC [277] livery guarantees. Because interaction is stateless, UDP is a is an experimental transport layer protocol to reduce latency candidate for multilateral One-to-Many Send on top of IP and redundant data transmissions in pro- broadcast or multicast, where datagrams are replicated by tocols. QUIC implements the SCTP multiplexing concept the networking infrastructure. on top of UDP to overcome the issue of SCTP being fil- tered by middleboxes. Similar to TCP Fast Open, latency is MultiPath TCP. A limitation of TCP is that segments even- reduced by removing handshakes between already familiar tually take the same network path, and a network problem hosts. QUIC allows transparent data compression, provides disrupts a connection until error handling routines or time- checksums and retransmission for reliability, and supports outs are triggered. This problem affects mobile devices in congestion avoidance. Forward error correction minimizes radio dead spots or during roaming between wireless net- obstructive retransmissions by an error-correcting code. In works. Particularly for mobile devices, it is more and more terms of patterns, QUIC offers bilateral Send and Receive. common that a device is connected to several physical net- works simultaneously, i.e., multihoming. MPTCP is a TCP Other transport protocols. There are several transport layer extension to increase both redundancy and transfer rate by protocols, where no evident application in a Web or cloud aggregating multiple paths over all available links as sub- context has been found. Examples for multilateral interac- flows of a single connection [41]. The MPTCP connection tion are multicast transport protocols [227]. Examples for does not fail if a path becomes congested or interrupted and bilateral interaction are: the message-based Datagram Con- an alternative path is still available. gestion Control Protocol (DCCP) [156] that offers conges- For compatibility with middleboxes, MPTCP is a host- tion control, but its delivery is unreliable; UDP Lite [162] side extension, and subflows are regular TCP connections. with relaxed checksums; and Reliable UDP (RUDP) [45] A notable example using MTCP is Apple Siri which utilizes as an extension of UDP with acknowledgments, retransmis- both Wi-Fi and 3G/4G networks for increased service avail- sions, and flow control. ability in mobile devices [19]. Communication in MPTCP is still bilateral like TCP, i.e., Send and Receive patterns. 4.3 Transport security Stream Control Transmission Protocol. TCP offers reliable delivery and strict byte order in the stream, but there are ap- Several standards for establishing secure sessions, indepen- plications that require reliability and ordering is less impor- dent from applications, have emerged to achieve confiden- tant; TCP can create unnecessary delays in such a scenario tiality, integrity, and authenticity in an interaction. This “vir- [303]. Also, the streaming nature of TCP introduces com- tual” security layer is situated between transport and appli- plexity in higher messaging protocols because streams then cation layer in the Internet model or in the OSI model’s ses- need a notion of state, delimiters to indicate message bound- sion layer. The most prominent protocols for encryption are aries, and measures to circumvent head-of-line blocking. the Secure Sockets Layer (SSL) [93] and Transport Layer Technologies for Web and cloud service interaction: a survey 11

Security (TLS) [68]. Both operate on top of TCP and estab- – Text-based or binary protocol; lish an encrypted session for byte-stream-based information – Stateful or stateless; exchange. Historically, SSL was invented by and – Combined or separated data and control connections. the latest version 3.0 became obsolete with TLS 1.0 in 1999. Application layer protocols assume properties of trans- Today’s TLS 1.2 still offers limited backward compatibility port, e.g., timing, and therefore restrict the allowed transport to SSL. layer protocols. Another distinction is whether their syntax To establish an encrypted session in SSL/TLS, an ini- is human-readable, and text-based protocols typically have tialization routine, i.e., SSL or TLS handshake, is necessary. an overhead because reduced information density. A proto- The most notable difference between SSL and TLS is when col is said to be stateful if the result of a previous interaction the handshake happens. An SSL handshake takes place im- affects the choice of the next interaction. Furthermore, pro- plicitly after the TCP handshake, independent from the ap- tocols can either mix control and content in a single connec- plication. TLS furthermore allows to trigger a handshake by tion or maintain separate connections. the application issuing the STARTTLS command to upgrade It should be noted that some protocols distinguish be- an already established TCP connection. During the hand- tween a conceptual high-level syntax and a wire format that shake, the communicating parties authenticate themselves is actually transmitted; e.g., while high-level syntax could using X.509 public key infrastructure and certificates, they be text-based, the effectively sent data could be compressed. agree on a cipher suite for the session, and securely ex- Two well-known text-based application layer protocols change session keys. The handshake requires several inter- are the (FTP) [262] and the Simple actions and adds a delay before encrypted communication Mail Transfer Protocol (SMTP) [155]. Both require TCP can proceed. For more details, the author refers the reader to and support TLS for security; while FTP maintains two sep- Rescola’s book [273]. arate TCP connections for text-based control commands and SSL/TLS only works with TCP because the data trans- binary media transfer, SMTP sends the text-based control fer is assumed to be correct and in order—a handshake or commands and the email message in a single TCP connec- session will fail otherwise. In MPTCP, subflows are regular tion. Both protocols are stateful because they require several TCP connections, and TLS is therefore supported [291]. But Send-Receive interactions, where success or failure of the TLS is not trivial for transport protocols using multiplexing current interaction decides the next action. such as SCTP and QUIC. If a single byte is lost or corrupt, all multiplexed streams will be stalled. SCTP also supports 4.4.1 unordered delivery of messages and partial reliability, which conflicts with the reliability and order assumptions of TLS The Domain Name System (DNS) [192,193] is an Internet [304,317]. One approach is to establish a TLS session for core service, managed by IANA, and specifies an applica- every individual stream in the multiplexed connection, but tion layer protocol. As names are more usable for humans the numerous TLS handshakes accumulate delays and affect than numeric addresses, DNS is a distributed for timeliness. TLS is therefore not an optimal choice to secure a hierarchical naming scheme that maps names onto IP ad- SCTP and QUIC. dresses. Records in DNS have a certain type; e.g., type A is a Datagram TLS (DTLS) [274] is a modification of TLS host address record, type CNAME is an alias for another name, that operates on top of UDP. It specifies a record type as or type MX is reserved for SMTP-service-specific records. message container, sequence numbers to detect out-of-order The hierarchical name of a host is then referred to as Fully records, and retransmission conditions. DTLS is defined for Qualified Domain Name (FQDN). other transport protocols, e.g., DTLS over DCCP [256] and DNS is a binary and stateless protocol implementing the DTLS for SCTP [317]. QUIC specifies its own cryptography Send-Receive pattern. A client queries a service to resolve a protocol loosely based on TLS, and all transmissions are en- name of a certain type, and the service eventually returns a crypted by default to avoid tampering by middleboxes [161]. record. DNS uses UDP as transport protocol for queries but also supports TCP for large responses or DNS transactions, i.e., zone transfers. The drawback of using TCP for short 4.4 Application layer protocols queries is the handshake delay. Application layer protocols define inter-process communi- DNS has become a critical service for today’s Internet, cation on top of transport protocols. These protocols are of- and the majority of services relies on DNS as an abstraction ten simple service protocols implementing the Send-Receive layer for locating endpoints; DNS service records (type SRV) pattern, where a server waits for incoming communication. even enable dynamic service discovery [58]. Nevertheless, They can be informally distinguished by properties: a failure, misuse, or misconfiguration in DNS can lead to unforeseeable security consequences; e.g., attacks like DNS – Transport layer assumptions; spoofing [112] are a serious threat. If DNS responses are 12 Harald Lampesberger

hierarchical part (location) Both HTTP request and response messages specify a header and an optional body separated by a delimiter. The http://www.ex.com/dir/fotos.php?action=view#page2 request header defines the method, the URI-path of a re- scheme authority path (identity) query fragment source, the protocol version, and a list of header fields. The presence of a body depends on the method. Similarly, the re- Fig. 9 An example URL identifies and locates a resource. sponse header holds a status code, a list of response header fields, and eventually a body, i.e., the requested content. tampered with, an attacker can redirect interaction to malign Header fields make HTTP extensible. Some headers are hosts. DNSSEC [21,22,23] is therefore an attempt to secure mandatory, others are optional. Content-Type is a central correctness and authenticity of queries and responses using header field to specify the MIME type of media. The content cryptographic methods. type of a requested resource is therefore undefined until the HTTP response message arrives at the client. 4.4.2 Resource identification and location Today’s HTTP/1.1 optimizes its predecessor versions in several ways. HTTP/1.1 supports eight methods: OPTIONS, A Uniform Resource Identifier (URI) is a human-readable GET, HEAD, POST, PUT, DELETE, TRACE, and CONNECT. The text string that identifies a resource in the Web. The URI Upgrade header enables the client and service to switch the specification [34] defines the syntax of a URI and also de- application protocol after a Send-Receive cycle. The Host scribes a Uniform Resource Locator (URL), a subtype of header distinguishes FQDN authorities that are hosted on URI that both identifies and locates a resource. the same server—a common practice in Web hosting. Fig.9 shows an example. The URI scheme identifies the Also, HTTP/1.1 introduces persistent TCP connections application layer protocol for accessing the resource and im- and pipelining of requests to minimize the accumulating de- plicitly assumes the default TCP or UDP service listening lay caused by the TCP handshakes for every requested re- port from a database maintained by IANA, e.g., ftp: for source. The standard proclaims that a client should not ex- FTP or mailto: for SMTP. The authority contains a Fully ceed two simultaneous TCP connections to a service. HTTP Qualified Host Name (FQHN) which is either a FQDN or an differentiates Content-Encoding of the requested resource IP address to locate the host of the service. Also, additional and Transfer-Encoding for transport-only compression user credentials and alternating TCP or UDP ports can refine between client and service. HTTP also offers fine-grained the authority. The path identifies a resource within the au- caching mechanisms, e.g., by timestamps, the ETag header, thority, an optional query part holds a list of key-value pairs, and conditional GET, such that clients and so-called proxies and an optional fragment can refer to specific information can minimize data transfer. within the resource. HTTP/1.1 allows client- or service-driven content ne- A URL has a notion of origin. Informally, two gotiation for resources [82]. In service-driven negotiation, share the same origin if they have identical scheme, FQHN, the service considers the client’s User-Agent, client-side and port [28]. As URLs have a fundamental role in the Web, content-type restrictions (Accept), accepted character en- there is a trend to simplify URLs to improve usability. So- codings for text-based formats (Accept-Charset), accepted called clean URLs [234] have an self-explanatory path and content encodings (Accept-Encoding), and personal natu- avoid the query part, e.g., the clean URL for Fig.9 is then ral language preferences (Accept-Language) for sending http://www.ex.com/fotos/view#page2. The rewriting a suitable representation. In client-driven negotiation, also of URLs into a clean form, automatically and manually, is a referred to as agent driven, the service returns a multiple- common practice in . choices status in a first response that lists all available rep- resentations, where the client can choose from in a second 4.4.3 The hypertext transfer protocol Send-Receive cycle. HTTP, originally specified in RFC 2616 [76], is the funda- While HTTP is stateless in principle, HTTP/1.1 adds mental application layer protocol for the Web and many ser- support for so-called cookies using the Set-Cookie and vice technologies. It is stateless and implements the Send- Cookie header fields to track state across Send-Receive cy- Receive pattern: A client sends a request message, and the cles [27]. A cookie is basically a text string that identifies a service answers with a response message. HTTP is designed client’s HTTP session. The responsibility for correct appli- to operate on top of TCP, and both control and content are cation state tracking is on the service side; cookies therefore sent in a single TCP connection, where control instructions have important security and privacy aspects. are text based. To separate control from data, HTTP speci- Recently, the HTTP/1.1 standard has been completely fies a header format and delimiters. Fig. 10 shows a Send- respecified in order to remove imprecisions that have led to Receive cycle between a client and a service. ambiguous implementations [77,78,79,80,81,82]. Technologies for Web and cloud service interaction: a survey 13

Service 2. HTTP Response

HTTP/1.1 200 OK Status Date: Mon, 02 June 2014 10:15:22 GMT Server: Apache Last-Modified: Mon, 01 June 2013 00:00:00 GMT Method, path GET /dir/fotos.?action=view HTTP/1.1 Accept-Ranges: bytes Host: www.ex.com Content-Length: 431 Connection: keep-alive Cache-Control: max-age=0, no-cache, must-revalidate Header fields Accept: */* Expires: Mon, 02 June 2014 10:15:22 GMT Header fields User-Agent: Mozilla 5.0 Etag: "4135cda4" Accept-Encoding: gzip,deflate,sdch Connection: keep-alive Accept-Language: en-US,en;q=0.8,de;q=0.6 Content-Type: text-html

1. HTTP Request Client

Fig. 10 After the client has established a TCP connection with the service, a request is sent as text-based stream. The service parses the request and returns a response containing a header and the resource through the other directional stream of the TCP connection. Depending on the HTTP method, a request eventually has a content, e.g., from a form submission or file upload.

HTTP security. The use of SSL/TLS for TCP connections first attempts have resorted to client-side polling, and real- has become the de facto standard to secure HTTP interaction time event notification was not possible. To minimize the between a client and a service, and it is specified as HTTP number of Send-Receive cycles and to decrease response Secure (HTTPS) [272]. As HTTPS has its own URI scheme times, long polling is similar to polling, but the HTTP re- (https:), a user can recognize from a URL whether the ac- quest hangs, i.e., is not answered, until a server-side event cess to a resource is protected. or a timeout occurs. A client can eventually choose to access an identical re- Comet [280], also known as HTTP Streaming or HTTP source through multiple transport mechanisms, e.g., HTTP server push, exploits persistent connections in HTTP/1.1 to or HTTPS. To notify a Web client that resources of a certain keep a single TCP connection open after a client requests an authority can only be accessed through HTTPS, the HTTP event resource. The service then gradually delivers events Strict Transport Security (HSTS) [116] specifies a response using MIME type multipart/x-mixed-replace for the header field that informs the client about this policy. response. Comet implements the Multi-Responses pattern. Using the CONNECT HTTP method, a client can ask a Reverse HTTP [164,96,297] exploits the Upgrade fea- proxy service to establish a connection to the intended ser- ture of HTTP/1.1 to change the application layer protocol vice on behalf of the client, and byte streams are forwarded. and switch the roles of client and service. The service be- This functionality, referred to as HTTP tunneling, is required comes an HTTP client in the established TCP connection, in proxies for HTTPS access to services. As exchanged data and real-time events are then issued as HTTP requests from are encrypted, caching is not possible. the original service to the original client, i.e., client-side Another way to secure HTTP interaction is to upgrade Receive-Send in terms of patterns. an existing TCP connection to a TLS session by using the For simultaneous bidirectional communication between Upgrade header in HTTP/1.1 [151]. A drawback of this so- client and service, Bidirectional-streams Over Synchronous lution is that a user can no longer see from a URL whether HTTP (BOSH) [247] maintains two separate TCP connec- access is encrypted or not. tions. The client uses the first connection to issue HTTP re- quest messages to the service, the second connection is a . In terms of patterns, a Send-Receive in- hanging request initiated by the client, so the service can in- teraction in HTTP is synchronous and can only be initiated teract with the client asynchronously. This enables patterns by the client; resources are pulled from a service. Due to Send and Receive for both client and service. wide availability of HTTP-enabled software and acceptance Two recent Web techniques in HTML5 are Server-Sent by middleboxes, HTTP has been exploited to achieve asyn- Events (SSE) [354] and WebSocket [75,355]. For SSE, the chronous interaction without breaking the protocol specifi- client requests a resource that acts as event resource similar cation, e.g., for client-side Receive or Multi-Responses pat- to Comet, i.e., implements the Multi-Responses pattern. The terns. These techniques are commonly referred to as push response is of MIME type text/event-stream, the TCP technology [3], so a service can push a resource to a client connection is kept open, and events are delivered as byte preferably in real time, e.g., for data feeds or event notifi- chunks. In case of a timeout, the client reconnects to the cation, without being explicitly requested. Historically, the event resource. 14 Harald Lampesberger

WebSocket establishes a bidirectional channel for simul- As SPDY changes the wire format of HTTP, encryp- taneous communication in both directions. A WebSocket tion is mandatory to prevent middleboxes from tampering connection behaves like a bidirectional byte-stream-oriented with interactions. SPDY requires TLS with Next Protocol TCP connection between client and service for Send and Re- Negotiation (NPN) support for backward compatibility with ceive interaction, and it is established in a handshake by HTTPS. When a client accesses an HTTPS service, the ser- exploiting the HTTP Upgrade header in HTTP/1.1. Dur- vice announces SPDY support through NPN during the TLS ing this HTTP Send-Receive cycle for the WebSocket hand- handshake, and the client can choose to proceed with SPDY shake, properties are negotiated using HTTP headers, in- or traditional HTTP within the TLS session. The experimen- cluding Sec-WebSocket-Protocol to agree on a subpro- tal QUIC transport protocol was specifically designed for tocol for continuation after the handshake. WebSocket sup- SPDY to remove delays between familiar hosts, caused by ports operation on top of TLS and provides individual URI the initial TCP handshake, and optimized flow control [277]. schemes for unencrypted (ws:) and encrypted (wss:) com- SPDY and WebSocket have been proposed as two core munication. technologies in the upcoming HTTP/2 which is currently in With respect to Comet, Reverse HTTP, or BOSH, Web- the specification process [245]. SPDY is already confirmed Socket has the smallest overhead because it is independent as the basis for HTTP/2, but protocol negotiation will be of HTTP when established. Nevertheless, clients and ser- switched from NPN to the more general TLS Application vices need an explicit application layer protocol to operate Layer Protocol Negotiation (APLN) mechanism in the fu- on top of a WebSocket connection. ture [30]. Contrary to SPDY, encryption in HTTP/2 is not mandatory; some implementations have stated that they will Performance and speed. Performance is an issue in HTTP only support HTTP/2 over an encrypted connection [126]. when many resources are requested simultaneously. Even when HTTP/1.1 persistent connections and pipelining are supported, access becomes somehow serialized because of 4.4.4 Web client-to-client communication limited simultaneous TCP connections. Allowing more par- allel connections has a negative effect on the availability of a A recent development on the client side, already supported service because there is an upper limit, how many TCP con- by many modern browsers, is Web Real-Time Communica- nections a host can serve simultaneously. A workaround for tions (WebRTC) [106,359] to enable direct interaction be- the connection limit is domain sharding [299]; resources are tween clients. The motivation is real-time information ex- distributed over multiple authorities, controlled by the ser- change without the necessity of a third-party service or bro- vice provider, so a client can use the maximum number of ker for video and voice calls to avoid network delays and TCP connections to every authority in parallel. In general, bottlenecks. there are a several approaches to increase Web performance WebRTC uses UDP as transport and still needs a ser- and user experience: vice for discovery and signaling between clients, but also – minimize protocol handshake latency; for dealing with NAT or firewalls on the path between two – reduce protocol overhead; clients. WebRTC is not limited to audio and video stream- – multiplexed access; ing. For general information exchange, WebRTC features a – prioritization of access. so-called RTCDataChannel to establish a direct SCTP as- sociation, protected by DTLS, between two clients [276]. Two standards that have never left the experimental sta- Interaction in WebRTC is message based and an associa- tus are the binary HTTP-NG [328], intended as a successor tion can provide ordering and reliable transfer. In terms of of HTTP, and multiplexing HTTP access over a single TCP patterns, an RTCDataChannel supports Send and Receive connection based on SMUX [329]. Other experimental mul- interaction between clients. tiplexing approaches are Structured Stream Transport [88] and HTTP over SCTP [198]. The state-of-the-art, Google SPDY [310], acts conceptu- 4.4.5 Messaging protocols ally as a session layer protocol between TCP and HTTP to increase Web performance through multiplexed resource ac- A increasingly popular group of protocols is designed for cess, prioritization, and compression of headers and content messaging passing, where peers interact through a message- to reduce overhead. SPDY changes the wire format, but re- oriented middleware or a service. Messag- tains the semantics of HTTP; it is basically an augmentation ing solutions often specify their own wire formats, i.e., ap- to HTTP and no individual URI scheme is specified for com- plication layer protocols, and this subsection enumerates the patibility reasons. SPDY also allows service-initiated inter- most important ones with respect to cloud computing. Ar- action to push related resources to the client before they are chitectures utilizing these protocols are then discussed in asked for, i.e., the Multi-Responses interaction pattern. Sect. 5.2.4. Technologies for Web and cloud service interaction: a survey 15

Proprietary wire formats. The Microsoft Message Queu- Web Application ing (MSMQ) [183] service specifies individual wire formats Web-Oriented View Web Syndication and utilizes TCP and UDP during interaction. Version 3.0 of Web Mashup MSMQ also introduces messaging through HTTP or HTTPS Architectures Remote Procedure Calls to overcome middleboxes. For sending messages to multiple SOAP/WS-* Services recipients on different hosts, MSMQ supports IP multicast, Service-Oriented View so message replication is implicitly performed by the net- RESTful Services work, and not MSMQ. Message-Oriented Middleware TIBCO offers several proprietary messaging solutions such as the Enterprise Message Service (EMS) [313] or Ren- Fig. 11 The survey distinguishes a Web- and service-oriented view on architectures dezvous [314] for enterprise and cloud messaging. While EMS utilizes individual XML-based message formats sent over TCP or WebSocket [315], Rendezvous uses a propri- The text-based Streaming Text Oriented Messaging Pro- etary binary message format sent over UDP and IP multicast tocol (STOMP) [305] is also an interoperable messaging for One-to-Many Send interaction. protocol that has resemblance to HTTP. It operates on top of The OpenMQ binary wire format is a protocol for Java a bidirectional byte-stream-based transport protocol such as Glassfish [98]. Another individual binary format is Open- TCP or WebSocket, supports TLS for encryption, and uses Wire [7] for Apache ActiveMQ [6]. [17] also UTF-8 as default character encoding. specifies a binary protocol on top of TCP transportation. Ze- MQ Telemetry Transport (MQTT) [125] is an open stan- roMQ [129] is an intelligent socket library for exchanging dard for lightweight messaging on top of TCP and low band- arbitrary binary messages, and ZeroMQ specifies a protocol widths as encountered in the Internet of Things. It defines a to split those messages into one or more frames for trans- binary message format with a small fixed-size header of only portation over TCP. two bytes and therefore little overhead. MQTT also supports SSL/TLS for encrypted transfers. The Constrained Application Protocol (CoAP) [296] is Standardized wire formats. Today’s most prominent open another standard for the Internet of Things, where hardware standard for messaging is the Advanced Message Queuing is typically constrained. CoAP has a binary message format Protocol (AMQP) [324]. The AMQP 1.0 transport model is for asynchronous messaging over UDP. The standard speci- an OASIS standard [211] that recently became the interna- fies mappings between CoAP and HTTP, and they have sim- tional standard ISO/IEC 19464 [140]. The transport model ilar semantics. CoAP offers optional delivery guarantees us- specifies a binary wire format that multiplexes channels into ing acknowledgments, supports Send-Receive, and also al- a single TCP connection or SCTP association. It supports lows multilateral interaction using IP Multicast. The stan- flow control for messaging, authentication [176], and en- dard refers to DTLS for securing CoAP interactions. cryption by TLS. AMQP is stateful because communicat- The Data Distribution Service for Real-Time Systems ing peers negotiate a session with a handshake after an TCP (DDS) [220] is a machine-to-machine middleware specifi- connection has been established. Peers exchange so-called cation with applications in the Internet of Things. DDS also frames that contain header fields and binary content. For specifies the Real-Time Publish-Subscribe (RTPS) [221] bi- interoperable representation of messages, AMQP offers a nary wire protocol for TCP- and UDP-based messaging, in- self-contained type system that includes a set of primitive cluding IP multicast for One-to-many Send interaction. datatypes, descriptors for specifying custom types, restricted datatypes, and composite types for structured information. This allows self-describing annotated content when interac- tion between heterogeneous platforms takes place. Known as Jabber, and initially motivated by portable 5 Architectures instant messaging, the Extensible Messaging and Presence Protocol (XMPP) [284,285] is another standard for mes- An architecture combines protocols, languages, and service saging. Short text-based messages, i.e., XML stanzas, are interaction patterns for service delivery. Fig. 11 describes bidirectionally exchanged in open-ended XML streams over the structure of this section. Architectures are distinguished a long-lived TCP connection, eventually protected by TLS, into a Web- and service-oriented view based on their evo- between a client and service or service-to-service. To over- lution: While the Web-oriented view explores typical Web come middleboxes, XMPP can utilize HTTP and push tech- scenarios, the service-oriented view focuses on well-known nology, i.e., BOSH [246]. Also, XMPP over WebSocket is architectures from enterprise service integration and cloud in an experimental state [307]. computing. 16 Harald Lampesberger

5.1 Web-oriented view After loading, the user has a choice of nonlinear continu- ations through . A refers to a URL, and The World Wide Web is all about hypermedia: To present when followed, a full page transition is triggered; the cur- multimedia content like text, audio, and video in a nonlinear rent DOM is replaced, and embedded resources are recur- fashion, where users can access information through hyper- sively loaded again. As common in Web 1.0, if a resource links. The Web has evolved through several phases that are changes on the service-side, the client needs to poll to rec- typically referred to by Web 1.0, 2.0, and 3.0 [74]. ognize changes, construct a completely new DOM and load While Web 1.0 refers to the advent of accessible hyper- all uncached resources. media, contents were often static, non-interactive and cre- For stateful page transitions, Web applications resort a ated only by few [63]. The key aspects of Web 2.0 are tech- unique identifier in the URL, in hidden form fields, or use a nological advances for dynamic content, interactive user in- cookie in HTTP to associate a client request to a service-side terfaces, and also a social community aspect; users can in- session to track application state. If a cookie has been set for teractively collaborate and create new hypermedia content. a particular origin, they are automatically added to HTTP Some examples are blogs, electronic marketplaces, or so- request headers. This allows, for example, an authenticated cial networking. Web 3.0 is believed to add personalization session spanning over several page transitions. based on semantics of content, for example, adaptivity to In terms of interaction patterns, a traditional Web appli- user preferences and context. The user experience in discov- cation inherits bilateral Send-Receive from its application ering knowledge is expected to go beyond merely following layer protocol HTTP or Multi-Responses in case of audio or hyperlinks and include social, mobile, and location aspects video streaming over HTTP. of the user. Web applications are discussed as the reference archi- Browser content policies. The same-origin policy on the tecture for hypermedia delivery, while Web syndication and client side is the fundamental security model of Web ap- mashups are a form of composition. plications. In general, the DOMs of markup documents re- trieved from different origins are isolated from each other 5.1.1 Web application for security reasons, including access and transmission of cookies. The same-origin policy applies to network-accessible A Web application, hosted on a webserver, delivers websites resources and script [196]. While the policy allows to clients. The components of a website are HTML/XHTML outgoing write access, e.g., form submissions, and static em- markup, CSS for visual representation, JavaScript code, and bedding of foreign resources in markup, dynamic read ac- media resources. Resources are uniquely identified by URLs cess during execution of script code is only allowed to re- and a client, i.e., a Web browser or user agent, requests them sources from the same origin. Access to a DOM and its APIs from a Web application using HTTP or HTTPS as transport through script code is also restricted. Script code is executed mechanism: in context of the DOM that embeds the script code. If two DOMs that share the same origin execute two scripts simul- – A website structures text content and media resources taneously, both scripts can fully access each other’s DOMs using HTML or XHTML markup. A client retrieves the and APIs. The same-origin policy enforces a coarse access markup and parses it into a DOM tree. control in Web browsers to isolate and separate interaction – The markup can define or refer to a CSS resource that between simultaneously active websites. specifies the visual representation of the DOM, e.g., col- The same-origin policy prevents Web applications from ors, fonts, images, or effects. using script code to dynamically compose resources from – The JavaScript runtime environment executes nested or different origins. A recent enhancement in browser security embedded script code in context of the DOM to interac- for a more fine-grained access control to foreign resources tively update the DOM tree during runtime. is Content Security Policy (CSP) [352]. CSP specifies ad- – The DOM is eventually rendered in a window. ditional HTTP headers and content type families. A service For composing multimedia and text, tags in the markup can then notify a client about trusted third-party origins with can refer to other resources via URLs. Depending on the respect to certain content type families of resources. content type of the resource, either predefined in the markup or announced in HTTP, the client either parses and presents Distributed authoring and versioning. One of the earliest the resource natively or hands it to an appropriate plugin standards for user collaboration over the Web is the Web during runtime. The HTTP optimizations discussed in Sect. Distributed Authoring and Versioning (WebDAV) [71] ex- 4.4.3 to minimize the delay experienced by the user tension for HTTP. While the first evolution of the Web has when multiple resources need to be loaded to compose a offered read-only content for most of the users, WebDAV website. adds write access such that users can edit resources together. Technologies for Web and cloud service interaction: a survey 17

This is accomplished by adding new methods and header linked data” [358]. Linked data are believed to be a major fields to the HTTP/1.1 standard; therefore, both client and characteristic of the Web 3.0. service have to implement this extension. Two widely used The W3C-proposed has three technologi- extensions of WebDAV are CalDAV [66] for shared calen- cal pillars: XML and Unicode as fundamental language; the ders and task lists and CardDAV [65] for sharing address (OWL) [353] to express relations; books. and the Resource Description Framework (RDF) [336] as a collection of specifications including vocabularies, a meta- data data model, and serialization formats. Asynchronous JavaScript and XML. A characteristic de- Several standards have been proposed to increase ap- velopment of Web 2.0 is toward dynamic Web applications plicability of W3C’s Semantic Web in today’s document- and improved user experience. Instead of full page transi- based Web. RDF through attributes (RDFa) [357] is an ex- tions, only parts in a DOM are updated during runtime us- tension to HTML and XHTML, where semantics of existing ing Asynchronous JavaScript and XML () [97]. AJAX markup are annotated using HTML or XHTML attributes. relies on the client-side XMLHttpRequest API to initiate Also, Microdata [356] for HTML5-based documents and HTTP or HTTPS interaction from script code. JSON for Linking Data (JSON-LD) [364] are annotation Instead of delivering a large HTML markup content that based and compatible with RDF. Microformats [177] is dif- requires substantial time for parsing and loading of embed- ferent annotation-based approach, independent from W3C ded objects, an AJAX-enabled Web application serves only a Semantic Web specifications. small markup skeleton and script code, so the client requests the slower-loading objects asynchronously and updates the HTML5 and assisting technologies. The numerous versions DOM when available. AJAX updates can also be triggered of HTML, XHTML, and ambiguities in their specifications by client-side events, e.g., user interface events. AJAX ex- have led to incompatible implementations or inconsistent vi- plicitly refers to XML as format for updates, but the mech- sual representations in Web browsers. Rich Web client func- anism can in fact accept any text-based content type, e.g., tionality has relied on plugins, e.g., , which had JSON, and process it by script code during runtime. a negative impact on the accessibility for many clients when HTTP push technology, as discussed in Sect. 4.4.3, e.g., the plugin was not supported. Comet or WebSocket, enables asynchronous near-real-time Today, HTML5 is an attempt to define an unambiguous updates from the service to the client in collaboration with syntax for a unified reference markup language and also to AJAX. User-experienced page load times and interactivity standardize APIs for a number of assisting technologies that therefore improve. have contributed to the success of Web 2.0 in building rich The same-origin policy applies to AJAX, i.e., accessing Web applications [363], such as: foreign resources through an XMLHttpRequest is consid- ered as a read access and only allowed to resources that share – Semantic annotation of markup through Microdata; the same origin as the executed script code. Cross-Origin – A set of natively supported audio and video formats; Resource Sharing (CORS) [361] allows – App Cache for offline storage of HTML5 websites; to a foreign resource, but this access has to be explicitly ap- – File System API for persistent storage; proved by the foreign Web application using HTTP headers. – and IndexedDB for temporary and offline For cross-origin access to JSON resources, when a client storage of client data; does not support CORS, there exists a workaround by script – Concurrent execution of script code by Web Workers; embedding, called JSON with Padding (JSONP) [137]. The – , also called cross-document messaging, same-origin policy does not apply to resources statically em- for controlled data exchange between DOMs of different bedded in markup. A JSON document is valid JavaScript origin; code, and JSONP exploits the script tag to load the JSON – Server-Sent Events (SSE) and WebSocket to increase in- document padded by script code from a specific URL. The teractivity of websites that require high responsiveness; padded script code then calls a user-defined function on the – Geolocation access for localized personalization. client side to process the JSON object. There are also non-W3C technologies to improve ca- pabilities of the client, in particular, WebGL [152] for 3D Semantic Web. Information in the Web is primarily encoded rendering support, and WebCL [153] for exploiting parallel in semi-structured HTML or XHTML documents, often us- computing hardware on the client. Also, the WebRTC API is ing natural language, which turns discovering, sharing, and available in many modern browsers today, but not part of the combining information into a hard problem. The Semantic HTML5 specification yet. HTML5 is an evolutionary step Web is an attempt to standardize formats, so the “Web of toward accessible websites and rich Web client experience documents” can become a machine-interpretable “Web of across Web browsers and mobile devices. 18 Harald Lampesberger

5.1.2 Web syndication ... C1 Cn C1 ... Cn While a Web application is a service for bilateral interaction with a client, the client needs to poll or rely on HTTP push Mashup Mashup ... technology to recognize service-side changes. Web syndi- cation propagates event notifications or push content from ... services to clients and also to other Web applications for Client Client service-to-service interaction, e.g., blogs. (a) Client-side mashup. (b) Service-side mashup. The simplest form of change notification is a service- Fig. 12 A mashup integrates n Web resources from different origins as side [166]. There are two parties: a peer that ex- Web components C1 ...Cn [282]. periences an event and triggers an HTTP request to a web- hook URL, and a routine that handles requests and processes posted information for the webhook URL. The definition of composability and reusability of resources which is also a a webhook is kept abstract, and there is only a trigger and a contributing factor for the success of the Web 2.0. A mashup handler in the spirit of callback or event programming. Lind- service, also called integrator, can be distinguished based say [167] further argues that callback principles in the Web on the location, where integration of Web components takes will eventually lead to the Evented Web, where, in terms of place [282,300]: service interaction, routing patterns and messaging between Web applications become feasible. A cloud PaaS that re- – Service-side mashup. When a client requests a mashed- lies on for distributed asynchronous processing up service, the service first gathers the foreign resources is Google’s App Engine [105]. from other origins, processes them, and returns the inte- Another approach to syndication is by so-called feeds or grated markup and media to the client. channels. Clients and Web applications can subscribe to a – Client-side mashup. A client-side mashup service re- feed offered by a syndication service to receive updates, i.e., turns a markup skeleton and script code, so the client a service-side One-to-Many Send interaction pattern. Two embeds components statically or loads them dynami- XML-based standards for feeds are the Rich Site Summary cally using AJAX. The client is then responsible for in- (RSS) [278] and the syndication format [200]. While tegration. RSS assumes HTTP as transport mechanism, Atom defines Fig. 12 shows both cases. Script code acts as a glue be- its own HTTP-based publishing protocol (AtomPub) [109]. tween Web components, and the information flow between A syndication service needs to initiate communication components can lead to security issues. Web components with the client when updates are available. A Web client therefore require proper encapsulation [170]. In terms of can either poll the syndication service’s feed or use HTTP patterns, a mashup enables one or more parallel bilateral push technology. For service-to-service interaction, a Web Send-Receive interactions between a client and Web servers application registers a webhook at the syndication service that host Web components, eventually routing messages be- to receive updates when available. A syndication service tween them. that pushes updates to clients has the role of a broker in a Client-side content policies lead to two extreme cases publish-subscribe architecture as shown in Fig. 16. Two im- of local script code interaction: no separation nor isolation plementations for syndication are PubSubHubBub [266] and by direct embedding in the same DOM using a script tag the AtomPub-oriented [8]. and strong separation and isolation by embedding in isolated The Bayeux protocol [281] is a push framework based DOMs using object or iframe elements. Ryck et al. [282] on Comet using named channels for a broker-based publish- survey the state-of-the-art techniques for more fine-grained subscribe architecture, i.e., One-to-Many Send interaction. controls in mashups, and they distinguish four categories of Clients subscribe to named channels, and the server pushes Web component integration restrictions: updates to all registered clients. An application of Bayeux is Web feeds. 1. Separation and interaction. Components are separated such that individual component DOMs and script code, 5.1.3 Web mashup e.g., global variables, are fully isolated from each other. Components can then interact through specified chan- A mashup composes so-called Web components, e.g., mul- nels, e.g., HTML5 offers the sandbox attribute for fine- timedia resources or script code, from different origins into grained iframe separation and Web Messaging for in- a new website [74]. Examples for mashup components are teraction between iframe objects. JavaScript libraries, gadgets [100], and services like Google 2. Script isolation. To isolate script code in components Maps. Web components and the mashup principle achieve when running in the same runtime environment, code Technologies for Web and cloud service interaction: a survey 19

can be restricted to a subset of allowed functions, and Client RPC Service static checking enforces an isolation policy. 3. Cross-domain communication. The same-origin policy SCallService Call SProcEntry denies cross-domain communication for script code by default during runtime. Techniques like CSP, CORS, or Return SProcEnd an XMLHttpRequest proxy allow read access according SContinue to a defined policy. 4. Behavior control. This category subsumes techniques to Transport Mechanism enforce policies on script code execution during runtime, e.g., reference monitors, access mediation to objects, or Fig. 13 RPC is conceptually a Send-Receive interaction. A client se- information flow control. rializes the arguments for a remote function call as a message, sends it to the RPC service, and waits for a response. To ease composability of mashup components, public API specifications, also referred to as Open APIs, have be- come popular in recent years. Open APIs can range from coupling. Services and middleware can still benefit from access to sophisticated service architectures loose coupling because evolving software systems become as discussed in Sect. 5.2. In particular, OpenSocial [232] is easier and cheaper to integrate [251]. This section surveys an initiative to standardize APIs for building social Web ap- architectures for offering services in cloud environments. plications. Integrating the social dimension is a step toward Four architectures are discussed: RPC, “big” Web services, personalized user experience, which is a characteristic of the RESTful Web services, and message-oriented middleware. Web 3.0. 5.2.1 Remote procedure calls 5.2 Service-oriented view RPC is a simple yet powerful architectural style to offer a Custom network protocols for enterprise application integra- service by exposing network-accessible functions [37]. In tion are often not forwarded over the Internet because mid- terms of patterns, RPC is bilateral Send-Receive between a dleboxes filter them. Using Web technology for integration, client and a service, as shown in Fig. 13. The client initiates e.g., in a middleware approach, ensures service availability the interaction, and if not stated otherwise, a network func- across the Internet. In our definition, a service has an in- tion call in RPC is synchronous and interfaces are statically terface that accepts and responds with a certain language. typed. Specifying an RPC service requires an agreed-upon According to the interface, services can be distinguished by: transport mechanism, e.g., TCP or HTTP, an agreement on how to address and bind to a remote function, and a data se- – Static typing. When the accepted language of a ser- rialization format to exchange structured data, e.g., ASN.1. vice is predefined by an Interface Definition Language Historically, one of the most widely deployed RPC solu- (IDL) or a grammar (e.g., a specific MIME media type, tions is Open Network Computing RPC (ONC-RPC) [312], a schema in XML, or a specification in ASN.1), the in- e.g., for network file systems. ONC-RPC originates from terface is strict. An implementation can be automatically , and APIs are available on practically all generated for the accepted language, e.g., a parser or major platforms. ONC-RPC uses TCP and UDP as transport stub code. mechanism, where call and return values are serialized in the – Dynamic typing. On the other hand, a service eventu- XDR format. ally accepts a set of content types, a language family, or RPC for distributed systems has evolved from function messages carry their own specifications, e.g., embedded calls to distributed computation over shared objects [327]. schemas. Interpretation is then runtime dependent, and Zarras [379] analyzes three prominent RPC-style middle- parsers need to be modular. Such a service interface is ware approaches that are based on object sharing: referred to as dynamically typed. – Microsoft Component Services (COM+) [182]; Typing affects coupling between clients and services. – The OMG-standardized Common Object Request Bro- Web applications, syndication, and mashups in the previous ker Architecture (CORBA) [222]; and section are dynamically typed because the content type of a – Java Remote Method Invocation (RMI) [238] in the Java resource governs the selection of a proper parser and seman- Platform, Enterprise Edition (Java EE) [236]. tics in the client. Web applications are loosely coupled. Statically typed service interfaces restrict flexibility and All three approaches define individual data serialization interoperability, e.g., the allowed programming languages, formats and support communication over the Internet pro- where stub code is available. The consequence is tighter tocols, in particular, TCP. While protocols and wire formats 20 Harald Lampesberger for COM+ are specified in the DCE/RPC standard [311], format or JSON and transport over TCP or HTTP. A notable CORBA uses the Internet Inter-ORB Protocol (IIOP) [223] RPC framework based on Thrift is Twitter Finagle [320]. for communication over TCP connections. Java RMI spec- Finagle enhances Thrift with multiplexing; Twitter’s Mux ifies individual protocols and wire formats on top of TCP, session-layer protocol is situated between TCP and Thrift, e.g., the Java Remote Method Protocol (JRMP) or Oracle so only a single connection between the client and the ser- Remote Method Invocation (ORMI), but also supports RMI vice is necessary to transport parallel Thrift interactions. over IIOP [239] for compatibility with CORBA systems. The three approaches enable shared objects in an RPC- Protocol Buffers. Google Protocol Buffers [99] define a style architecture. An object broker for allocation, garbage platform-neutral language for specifying a data structure, collection, and transactions is implicitly required [327]. To similar to ASN.1. Tools translate a specified structure into represent a shared object on the client side, a stub abstracts stub code for compact binary serialization and deserializa- away the serialization and communication. The service in- tion. RPC services using Protocol Buffers are therefore stat- terface is therefore statically typed. A recent middleware ically typed. There are no restrictions on transport mecha- framework, similar to CORBA, but compatible with Web nisms or message exchange. As long as both parties have protocols, is the Internet Communications Engine [380]. stub code generated for the same specified structure, mes- sages can be exchanged, e.g., over HTTP. Google claims that XML- and JSON-RPC. A basic architecture for a Web-based their internal RPC services rely on Protocol Buffers [99]. RPC is XML-RPC [293]. Call and return information is seri- alized as text-based XML, and HTTP transports request and Hessian and Burlap. Hessian [54] is a protocol for RPC response documents to a service identified by a URL. While Web-based services, where structured information is serial- XML-RPC defines a subset of XML by specifying rules how ized in a compact binary format. This message format is dy- datatypes are serialized using tags and attributes, an XML- namically typed, designed for efficient processing, and in- RPC service is still dynamically typed because there is no tended for HTTP transportation. No IDL is therefore neces- schema for an actual service interface. The XML-RPC De- sary for a Hessian service. Burlap [53] is semantically the scription Language (XRDL) [375] is an attempt to define same protocol as Hessian, but uses an XML-based data se- XML-RPC services in the spirit of an IDL, so client-side rialization format. stub code can be automatically generated. JSON-RPC [194] is related to XML-RPC, with the dif- 5.2.2 SOAP/WS-* Web services ference that the specification does not restrict itself to any transport mechanism. JSON-RPC only specifies call and re- Many RPC architectures require static typing in an IDL and, turn formats based on the JSON format. as a consequence, have tight coupling from code restrictions. The goal of so-called big Web services is to relax this cou- Apache Avro, Etch, and Thrift. Several proprietary imple- pling by open standards for heterogeneous platforms [251]. mentations for RPC-style service interaction have been pro- A deals with XML documents and document posed, especially for high-performance provider-side back- encapsulation to evade the complexity of distributed compu- end services in clouds. Apache Avro [13] is both a data se- tation on shared objects [327]. The core technology in this rialization format and an RPC mechanism in the Apache attempt is the Simple Object Access Protocol (SOAP) [344] Hadoop [16] project for big data analysis. Transportation of for expressing messages as XML documents. messages in Avro is protocol independent in general, but the SOAP is transport-agnostic by design and supports all specification explicitly refers to HTTP. Avro supports dy- kinds of transport mechanisms, including message-oriented namic typing; a serialized message is accompanied by its middleware. However, HTTP has become an industry stan- schema in JSON format. dard for because of its middlebox compatibility [107]. Web The Apache Etch [11] framework originates from Cisco services standards (referred to as WS-*) extend SOAP-based Systems. It defines a service description language, similar to interaction with security, reliability, transaction, orchestra- an IDL, a binary serialization format, and TCP is assumed tion, workflow, and business process aspects. for transportation. A compiler generates stub code for the client and service sides of a specified architecture, and mes- Technologies. In accordance with Alonso et al. [4], tech- sages are therefore statically typed. nologies for Web services are categorized into four groups: [10], developed by Facebook, is a - work that specifies an IDL for RPC-style services and tools – Service description. The XML-based Web Services De- for statically typed stub code. While transportation and seri- scription Language (WSDL) [332] is a format to de- alization of messages is kept abstract, Thrift provides several scribe Web services similar to an IDL. While coupling default procedures, e.g., serialization in a compact binary between Web services is loose due to XML, interfaces Technologies for Web and cloud service interaction: a survey 21

Transport Mechanisms Middleware Composition, Choreography, Orchestration service interface Properties Security, Reliability, Transactions implements in Protocol op1 Coordination endpoint1 out Infrastructure

binding1 SOAP in Messaging op2 endpoint2 out SOAP Msg. Security HTTP endpoint3 binding2 in opn out Transport SSL/TLS TCP Concrete Section Abstract Section Internet/Networking Fig. 14 A WSDL 2.0 service definition characterizes an interface as a set of operations. A binding assigns a concrete transport mechanism Fig. 15 The Web services interaction stack [4] in accordance with to an abstract interface, e.g., SOAP over HTTP. A service then imple- the WS-I Basic Profile [367,368] is restricted to SOAP over HTTP ments an interface in a set of endpoints, i.e., addresses, for bindings. as transport mechanism

– Service composition. Network-accessible operations al- and messages in the SOAP/WS-* stack are nonetheless low Web services to be composed. In terms of interac- statically typed in WSDL. tion patterns, a basic Web service that computes a result A WSDL version 2.0 document has an abstract and a implements Send, Receive, or Receive-Send. A compos- concrete section, as shown in Fig. 14. The abstract sec- ite service consumes other services, and according to the tion defines a type system of one or more XSDs to spec- application logic, it allows more advanced interaction ify message formats; one or more interfaces and their patterns. operations; and an assignment of input and output message types to operations. Every operation has a mes- Due to the large number and many versions of WS-* sage exchange pattern: in for Receive, out for Send, standards, the Web Services Interoperability Organization and in-out for Receive-Send interaction. (WS-I) establishes best practices for interoperability, pub- The concrete section in WSDL describes how abstract lished as Basic Profiles [367,368]. Figure 15 is limited to interfaces become network accessible. A binding asso- basic profile protocols and standards for transport and mes- ciates a specific transportation mechanism, e.g., SOAP saging. over HTTP, to an abstract interface. Finally, a service implements an abstract interface by specifying a set of endpoints. An endpoint associates an accessible ad- SOAP attachments. A SOAP message has an envelope dress (URL), where the service can be consumed, to a root element that holds a header element for metadata and concrete binding. a body element for the message content. The structure of the – Service discovery. Services described in WSDL need body has to obey the schema of its according WSDL mes- to be published to enable automatic discovery or dy- sage type, and a service can therefore validate messages. namic late binding. The XML-based Universal Descrip- Base64 allows to encapsulate arbitrary binary data as tion, Discovery, and Integration (UDDI) [202] standard- XML-compatible text, but incurs a blowup in size. Rele- izes a registry for classifying, cataloging, and managing vant metadata, e.g., the MIME type of the binary content, Web services. Such a registry is typically offered as a is not preserved in a standardized way. Several techniques SOAP/WS-* Web service. have therefore been proposed for dealing with binary con- – Service interaction. To access operations, clients and tent in SOAP. services need to communicate SOAP messages. Alonso Two historical standards are SOAP Messages with At- et al. [4] introduce the notion of a service interaction tachments (SwA) [331,337] and Microsoft’s DIME. SwA stack, as shown in Fig. 15. The stack has four layers: relies on MIME multipart [165] as container format, where transport of messages by HTTP, eventually protected by XML-based SOAP is the first part, and subsequent parts SSL/TLS; messaging through SOAP; a protocol infras- have individual MIME types and encapsulate binary con- tructure to coordinate a number of services using meta- tents directly. DIME operates in the same spirit but with a protocols; and middleware properties with respect to se- different container format. As there are different types of curity, reliability, transactions, and orchestration of ser- MIME multipart containers for SwA, the WS-I has pub- vices. lished the Attachments Profile [366] for interoperability. 22 Harald Lampesberger

its destination is met. WS-Security [204] defines standards Publisher Publisher for end-to-end cryptography methods, including XML sig- publish publish natures and encryption for SOAP messages. WS-Trust [214] and WS-SecureConversation [210] extend WS-Security by Broker establishing a security context for communicating parties to subscribe subscribe subscribe speed up the cryptographic key exchange. The WS-Policy [345] framework for Web services de-

Subscriber1 Subscriber2 Subscriber1 Subscriber2 fines a language for specifying and advertising policy as- (a) Broker service. (b) Peer-to-peer publish- sertions, e.g., security or Quality-of-Service policies. WS- subscribe. SecurityPolicy [213] is an extension of WS-Security to ex- press security-specific policies. Fig. 16 Publish-subscribe can either use a broker- or peer-to-peer- based architecture to facilitate multilateral service interaction patterns Another issue that arises in a messaging context is re- liable message delivery. WS-Reliability and its successor WS-ReliableMessaging [209] specify procedures, so deliv- The state-of-the-art SOAP Message Transmission Opti- ery is guaranteed through acknowledgments even for routed mization Mechanism (MTOM) [342] resorts to XOP pack- SOAP messages. aging if a WSDL input message type defines an element an- notated with a certain MIME content type. From the ser- Protocol infrastructure and middleware properties. To ex- vice’s WSDL, the client becomes aware that MTOM is ac- ploit SOAP messaging in SOA, standards for coordinating cepted. If a client does not support MTOM, Based64 is used and composing services to model business processes are re- as fallback encoding. quired. A notable standard for such a protocol infrastructure is WS-Coordination [208] to coordinate actions of multi- Messaging. The SOAP standard does not specify how mes- ple Web services. WS-Coordination enables distributed ac- sages are routed, whom to respond to in asynchronous com- tivities like transactions (WS-AtomicTransaction [206]) or munication, or where to report errors. SOAP is in a sense business activities (WS-BusinessActivity [207]). similar to RPC; the operation is completely defined by its Beraka et al. [33] review standards for Web service com- endpoint address, e.g., a URL for a HTTP transport binding. position and orchestration. Examples for composition and WS-Addressing [338] specifies two core constructs to orchestration modeling are the Business Process Model and enable routing patterns: endpoint references and message Notation (BPMN) [224], Business Process Execution Lan- addressing. An endpoint reference is an address, i.e., URL, guage (BPEL) [205] and WS-Choreography [343]. and optional parameters for communicating with the end- point. Addressing information is stored in the SOAP header, e.g., a semantic message identifier (wsa:Action), destina- Software implementations. In the Java world, there are sev- tion endpoint references (wsa:To), routing or relay endpoint eral APIs supporting SOAP/WS-* Web services integration references (wsa:ReplyTo), or endpoints for error handling like JAXM [143] for SOAP integration, the obsoleted JAX- (wsa:FaultTo). Based on addressing information, a service RPC [142], and its successor JAX-WS [144] for Web ser- can dynamically forward SOAP messages to other services vices. The most notable implementations using those APIs to implement all kinds of interaction patterns. are [9], Apache CXF [14], GlassFish [146], WS-Eventing [351] and WS-Notification [203] are two IBM WebSphere [123], JBoss [243], Oracle Weblogic [240], competing standards for publish-subscribe messaging on top and XML Interface for Network Services (XINS) [108]. of WS-Addressing. In terms of interaction patterns, publish- Furthermore, the Windows Communication Framework subscribe is One-to-Many Send from point of view of a pub- (WCF) [186] is an API and runtime environment in Mi- lisher. Publish-subscribe either needs a broker service or the crosoft’s .NET framework that relies on SOAP/WS-* for publisher manages subscriptions individually, as shown in services integration. Fig. 16. A broker stores subscribed endpoint references and distributes messages from publishers. So, broker-based pub- 5.2.3 RESTful services lish-subscribe allows a publisher to address an anonymous group of receivers. Fielding [83] has coined the term “Representational State Transfer” (REST) as an architectural style for distributed Security and reliability. SSL/TLS in HTTPS bindings in hypermedia systems. REST for resource-oriented architec- SOAP only ensures encryption between the client and ser- tures has become a key technique in the Web and cloud ser- vice endpoint, but according to WS-Addressing, a SOAP vices to achieve simplicity, scalability, and shareability. In message could traverse multiple services or brokers until its original form, REST is rather abstract and not restricted Technologies for Web and cloud service interaction: a survey 23 to specific protocols. However, the principles have been de- RESTful Service Client rived from successful Web architectures and early versions GET /cart of HTTP. That is why REST primarily refers to HTTP as SNeedCart /product/1 transport mechanism today. SAddProducts GET REST emphasizes a unified interface between compo- GET /product/2 nents and abstraction of information as resource. Four inter- /product/3 face constraints for an architectural style to be considered SOrder PUT RESTful are established by Fielding [83,85]: /order

1. Identification of resources. A REST service offers a set HTTP Interaction of resources that need to be identified, so clients can in- teract with them. URIs are well known for resource iden- Fig. 17 A client interacts with a RESTful service, keeps track of ap- tification in the Web and also for REST. HTTP is the plication state locally, and applies HTTP methods on resources. From protocol of choice for interaction. the cart, the client discovers URLs of products and order placements. 2. Manipulation of resources through representations. A representation of a resource is a sequence of bytes plus and REST is an extreme case of dynamically typed in- metadata that describe those bytes using a content type. terface. The hypertext-driven presentation enables loose A representation captures the current state of a resource, coupling, maximum freedom in resource namespaces, and REST operations applied to a representation modify and allows dynamic discovery of resources. the resource’s state. REST reuses HTTP methods as uni- fied operations on resources. So, existing infrastructure There has been an extensive debate in the literature on such as caches or proxies stay compatible with REST, REST versus SOAP/WS-* over the years [251,252,264], in- which in turn gives high scalability for PaaS or SaaS en- cluding a quantitative comparison by Pautasso et al. [253] vironments. The following HTTP methods are defined with respect to degrees of freedom in both architectures. as operations: While SOAP/WS-* standards precisely define how to im- – Method PUT creates a new resource from a trans- plement certain properties of a service, REST is a number ferred representation. of principles that outline characteristics that a service needs – The idempotent method GET reads a representation to satisfy. This freedom-of-choice in REST has led to many of a resource’s current state. services that claim to be RESTful but are in fact RPC [84]. – Method POST updates the state of a resource to the transferred representation. Technologies. In comparison with SOAP/WS-* Web ser- – Method DELETE deletes a resource. vices, technologies for REST can also be grouped into four 3. Self-descriptive messages. A resource can be repre- categories of purpose: sented in various formats, e.g., HTML, XML, or JSON, so a client can choose or negotiate a viable representa- – Service description. APIs for RESTful services are of- tion. On the other hand, a resource’s metadata allow de- ten just documented in natural language on a website, cision making for caching, content negotiation, check- e.g., Open APIs for mashups. There are two attempts sums, authentication, and access control [253]. in machine-interpretable RESTful service descriptions: 4. Hypermedia as the engine of application state. Interac- WSDL 2.0 [332] and the Web Application Description tion with a resource is stateless and, in terms of inter- Language (WADL) [348]. The latest version of WSDL action patterns, Send-Receive for a client. A RESTful supports non-SOAP messages and has more fine-grained service only manages resource state, and the client is re- control over HTTP bindings to turn them RESTful. sponsible for tracking application state, as shown in Fig. WADL is a description language for HTTP-based Web 17. A pure RESTful service in Fielding’s definition has applications to enable modeling or automatic stub code no notion of session as common in Web applications; generation for RESTful service APIs. WADL is XML every Send-Receive interaction has to be self-contained. based and allows to describe a set of resources, relation- A client accesses a RESTful service through a single en- ships between resources, available methods, and repre- try point, i.e., a , and the service returns hy- sentations for a resource. Furthermore, WADL supports pertext as simultaneous presentation of information and XSD and Relax NG as schema languages for XML re- control [84]. The hypertext outlines the choices a client source representations. can take at a specific state; choices are basically hyper- – Service discovery. Resource discovery in REST is dy- links that point to continuation URIs. Interpretation of namic due to the “Hypermedia as the Engine of Appli- a resource then depends on its MIME media type. Ap- cation State” principle. In Fig. 17, the cart resource is plication state is handled completely on the client side, the entry point and provides hyperlinks to products, so 24 Harald Lampesberger

the client discovers its choices and proceeds to the next Peer Peer2 Peer internal application state. Peer2 Peer3 1 3 Discovering a service is then uncovering an entry point, Message-Oriented i.e., bookmark or hyperlink. Entry points can be man- Peer1 Peer4 Middleware aged in registries accessible as a service, e.g., Google Peer Peer APIs Discovery Service [101], announced by syndica- Peer6 Peer5 6 Peer5 4 tion services, e.g., AtomPub, or defined in DNS-based (a) Peer-to-peer messaging. (b) Broker-based messaging. service records [58]. Fig. 18 A message-oriented middleware abstracts communication be- – Service interaction. Formats of SOAP/WS-* messages tween heterogeneous peers. A broker can reduce the communication are inherently XML-based and specified in a WSDL. complexity [64], and a peer can participate as service, client, or both. REST does not restrict representations of resources and allows free usage of existing and custom MIME types. Popular text-based formats in REST are plain-old XML allows Send-Receive interaction using separate or piggy- (POX), JSON, and YAML. As long as metadata refers to backed acknowledgments depending on the time needed to a MIME type supported by the client, the format is valid. prepare a resource representation. The protocol furthermore REST is bilateral interaction between client and service; supports multicast for One-to-Many Send and One-to-Many multilateral messaging, like WS-Addressing in SOAP- Send-Receive messaging and specifies service discovery to based Web services, is not standardized. An application implement REST principles in constrained environments. of REST with respect to messaging is a Web-accessible interface for a message-based middleware (discussed in Software implementations. REST is more an architectural Sect. 5.2.4). style than a set of technologies, and RESTfulness is achiev- – Service composition. Today, composition of RESTful able in all kinds of Web frameworks or programming envi- services primarily takes place in Web mashups, where ronments, e.g., for mashups [100]. resources serve as Web components. There are also at- Specifically in the Java world, the JAX-RS API [145] tempts toward composition in JOpera [248] and work- has been introduced for RESTful services, and practically all flow orchestration by BPEL for REST [249], BPMN for mentioned SOAP/WS-* software implementations support REST [250], or the JavaScript-based S language [42]. it too. Other notable implementations and frameworks are the REST extensions in Microsoft’s WCF [186], the PaaS Hi-REST and Lo-REST. Pautasso et al. [253] distinguish Restlet [275], and the Web Resource Modeling Language HTTP-based implementations into Hi-REST and Lo-REST: (WRML) [174] framework for RESTful API design. Hi-REST uses the four HTTP methods for operations, POX for data serialization, and resources have “nice” URIs. But 5.2.4 Message-oriented middleware many Web browsers are limited to HTTP methods GET and POST which restricts available REST operations when inte- To cope with increasing demands on scalability, flexibility, grated in Web applications or mashups. Lo-REST deals with and reliability, a message-oriented middleware (MOM) is an these restrictions and, as a workaround, exploits an HTTP infrastructure for loosely coupled interprocess communica- header or a hidden form field to store the actual REST op- tion in an enterprise service bus or clouds [64]. Especially in eration that needs be applied. This of course affects caching clouds, loose coupling allows to rapidly scale message pro- infrastructure. ducers and consumers. A message with respect to MOM is an autonomous, self-contained entity that models an event Security and reliability. For secure exchange of represen- and separates into a header and a body or payload. The mid- tations, REST relies on SSL/TLS in HTTPS. Only the con- dleware provides technical means of exchange, so a peer can nection between client and service is secured this way, there exchange messages with other connected peers. is no standardized end-to-end security in a messaging con- A central concept in MOM is the notion of a message text, like WS-Security. Furthermore, REST over HTTP has queue (or channel) for storing, transforming, and forward- no standardized reliable delivery nor transaction handling ing messages. Message queues enable asynchronous interac- compared to SOAP/WS-* Web services. tion, and a simple form is a First-In-First-Out (FIFO) queue. There are two different approaches to MOM using message Constrained RESTful environments. CoAP [296] is an al- queues as shown in Fig. 18: ternative to HTTP in constrained environments, where com- putational power and memory are limited, i.e., the Internet – Peer-to-peer messaging. A unified middleware compo- of Things [295]. CoAP is designed to easily integrate with nent in every peer coordinates discovery and interaction HTTP, e.g., by sharing methods, URIs, and media types, and between peers. Technologies for Web and cloud service interaction: a survey 25

– Broker-based messaging. The middleware acts as a bro- Java Message Service. The general purpose API named ker to provide a messaging infrastructure between the Java Message Service (JMS) [237] is maintained in a Java heterogeneous peers. community process for MOM support. JMS defines a num- ber of operations for creating, sending, receiving, and read- Peers can participate as client, service, or both [64]. A ing messages. It is transport-agnostic to abstract messaging broker reduces the communication complexity between a from MOM implementations and therefore relaxes vendor number of peers but can incur delays in real-time applica- lock-in. JMS is a universal interface for interacting with het- tions because an additional store-and-forward procedure is erogeneous messaging systems [64]. A message body is dy- necessary. namically typed according to the content type information In terms of interaction patterns, a trivial stored in the header. allows bilateral Send and Receive, for asynchronous mes- Some examples for JMS-enabled software implementa- saging, and multilateral One-to-Many Send, e.g., publish- tions are the JMS reference implementation OpenMQ [98], subscribe. Using message queues in a broker architecture IBM Websphere MQ [124], or TIBCO Enterprise Message allows to implement sophisticated routing patterns. In gen- Service [313]. eral, a MOM is characterized by Curry [64]: RESTful Messaging Service. The motivation for RESTful – Messaging specification. A MOM needs to specify the Messaging Service (RestMS) [370] is Web-compatible mes- format of messages and transport mechanisms. Intercon- saging by using HTTP as transport mechanism and REST necting proprietary MOM systems is achieved through principles to describe locations, i.e., URLs, where messages adapters or bridges. can be posted to and received from. RestMS is an API spec- – Message filtering. A core functionality of a MOM is ification, where XML-based messages are sent and received filtering for message delivery. Curry [64] distinguishes: using HTTP methods. With respect to the REST service, – A channel-based system offers predefined groups of resource locations are distinguished into feeds for incom- events as channels, where clients can subscribe to. ing and pipes for outgoing messages. Feeds are joined with – Messages in a subject-based system carry metadata pipes on the service-side for message distribution. Message in the message header, e.g., a subject. A client sub- types in RestMS refer to XML, JSON, and a set of MIME scribes messages, where the metadata matches some content types for dynamically typing data. The specification given pattern. also includes profiles to connect to other messaging infras- – In a content-based system, a client subscribes mes- tructures, e.g., AMQP. sages, where the message body satisfies a set of prop- erties expressed in a query language. Open Middleware Agnostic Messaging API. Due to the di- – Composite events functionality extends a content- versity in middleware standards and wire formats, the Open based filtering with property matching across sets or Middleware Agnostic Messaging API (OpenMAMA) [231] sequences of messages. initiative is an attempt to provide a single API for developing – Message transformation. Messages can originate from applications spanning across multiple MOMs. For correct various heterogeneous sources and consequently carry translation messages and operations, a MOM has to provide all kinds of content types as payload. A MOM can offer a so-called OpenMAMA bridge implementation. APIs to modify messages, e.g., XML transformations. OpenMAMA is available as open-source library. It of- – Integrity, reliability, and availability. A MOM can have fers a built-in bridge for AMQP-enabled and properties to increase the overall Quality-of-Service: supports several bridges for proprietary messaging infras- – Transactions and Atomic Multicast Notification; tructures in the finance sector. – Reliable message delivery: at-least-once, exactly-on- ce, or at-most-once; Proprietary messaging solutions. MSMQ [183] is a MOM – Guaranteed message delivery by acknowledgments; for standalone integration or as a transport mechanism in – Prioritization of messages; Microsoft’s WCF, next to Web services and COM+. It of- – Load balancing over several brokers or queues; and fers guaranteed message delivery, message routing, transac- – Message broker clustering for fault tolerance. tions, prioritization, and a simple type system for message body types. When used as a transport in WCF, a message A MOM is typically accessed through an API to ab- body is either XML, binary, or ActiveX format. Beside its stract the technical details of message exchange. Due to the proprietary protocols, messages can also be transmitted over transport-agnostic design of SOAP/WS-* services, a MOM COM+. In terms of security, MSMQ allows authentication can also serve as a transport mechanism for SOAP mes- and encryption of messages. There is no broker in MSMQ; sages. similar to Fig. 18(a), a queue is hosted locally on a peer, and 26 Harald Lampesberger

Message Message which is responsible for delivering messages to queues. An key=“news” key=“news.wsj” exchange can be offered as a service, and there exists an individual URI scheme (amqp: or amqps:)[257] to locate Exchange Exchange an exchange. A binding is a set of queue-specific arguments for an exchange. As shown in Fig. 19, there are different binding = “news” binding = “news.*” exchange types with respect to message filtering capabili- Queue Queue ties [228]: (a) Direct exchange. (b) Topic exchange. – In a direct exchange, a message has a routing key and Message is sent to the queue, whose binding is equivalent to the Message routing key. In case of multiple queues with identical Exchange bindings, multiple message copies are delivered, i.e., a Exchange channel-based system. binding = match binding = “#” “type=log ∨ report” – A topic exchange forwards copies of a message to all client queues, where the message routing key matches a Queue Queue Queue queue’s binding pattern, i.e., a subject-based system for (c) Fan-out exchange. (d) Headers exchange. publish-subscribe delivery. Fig. 19 AMQP defines four types of exchanges. A producer creates a – In a fan-out exchange, messages are forwarded to a set of message and sends it to an exchange. Depending on the exchange type queues without a specified binding, i.e., channel-based and bindings, the message is delivered to queues, where consumers can system. fetch it from. – A headers exchange matches the headers of a message against predicate arguments of client queues beyond the processes can store and retrieve messages. In terms of ser- routing key, i.e., a content-based system. vice interaction patterns, MSMQ is bilateral Send and Re- ceive. MSMQ can exploit IP multicast to replicate a message Messages are finally fetched from queues by consumer for addressing multiple queues. A Microsoft alternative with processes. AMQP provides guaranteed delivery, authentica- brokerage support is SQL Server Service Broker [185]. tion, wire-level encryption, and transaction-based messag- Other proprietary MOM software products are the bro- ing for reliability. In terms of patterns, an exchange applies kerless TIBCO Rendezvous [314], which uses direct con- pattern Send in case of direct delivery or One-to-Many Send nections between peers similar to MSMQ, Oracle Tuxedo in other cases. Due to the self-contained type system and Message Queue [235] as part of the Oracle Tuxedo applica- self-describing message content, messages are dynamically tion server for cloud middleware, and Terracotta Universal typed in AMQP. Messaging [298]. Examples for JMS-compatible broker implementations are OpenAMQ [128], JORAM [147], WSO2 Message Bro- ker [374], SwiftMQ [308], Apache Qpid [12], and Red Hat Advanced Message Queuing Protocol. Historically, MOM Enterprise MRG [271]. solutions have relied on proprietary protocols, and JMS is an attempt to agree on a compatible interface. Interoperability between varying MOM solutions is still difficult; costly JMS Extensible Messaging and Presence Protocol. While the adapters or bridges are necessary to connect different trans- XMPP [283,284,285] has been intended as an open stan- port mechanisms. AMQP [211] unifies messaging through dard for instant messaging, presence information, and con- an agreed-on wire format and has a similar role like HTTP tact list maintenance in chat applications, it also has middle- in Web applications. While the OASIS AMQP 1.0 standard ware properties. In its base specification, XMPP exchanges is restricted to the transport model for interoperability over messages as XML stanzas in client-to-service and service- the Internet, messaging architectures are specified by the to-service communication for federated services. An XMPP AMQP working group [216]. service therefore takes the role of a broker. The AMQP specification distinguishes a transport model XMPP is particular attractive for MOM scenarios, where (discussed in Sect. 4.4.5) and a queuing model [228]. The Web agents are involved because it supports HTTP as trans- semantic queuing model defines terms like message, queue, port mechanism and most Web browsers and JavaScript run- exchange, and binding with respect to AMQP. Messages al- time environments are capable of processing XML stanzas. ways end up in queues which are analogous to postal mail- Furthermore, XMPP is also considered as a suitable messag- boxes. A queue stores messages and offers functionality for ing protocol for Internet of Things applications [376]. The searching, reordering, or transaction participation. If a client protocol is extensible and extensions are specified in a com- wants to send a message, it chooses a broker-like exchange munity process. MOM-specific extensions are: Technologies for Web and cloud service interaction: a survey 27

– Transfer of Base64-encoded binary content with an as- Two notable MQTT broker software implementations signed MIME media type [286]; are HiveMQ [115] and Mosquitto [195]. Both support Web – RPC over XMPP [2]; clients using WebSocket. Another application that relies on – Service discovery [113]; MQTT messaging is Facebook Messenger [381]. – Publish-subscribe [189] for broker scenarios, extended addressing [114] for message routing, and event notifi- Data Distribution Service for real-time systems. The open cation extensions [365,287]; standard DDS [220] specifies a machine-to-machine MOM – Reliable message transport [190]; and for publish-subscribe message distribution, real-time mes- – SSL/TLS protected transport mechanism and S/MIME sage delivery, scalability, and high throughput. Fields of ap- [270] for end-to-end message encryption. plication include the finance and defense sector, industry, By default, messages in XMPP are XML stanzas and aerospace, Internet of Things, and mobile devices [318]. bodies are restricted to text only; there exists a notion of Contrary to MQTT, DDS facilitates a data-centric, peer- message type, but it is limited to instant messaging appli- to-peer interaction in the spirit of Fig. 18(a).A domain par- cations. Therefore, out-of-band signaling or a custom proto- titions entities such as publisher, subscriber, and topic. A col, e.g., XMPP bits of binary [286], is required to discover topic in a domain has a unique name and a strong datatype message content types in a middleware scenario. for publishing; these types are specified in an IDL, and mes- XMPP can also serve as a messaging infrastructure for sages are therefore statically typed. Subscribers in the do- SOAP/WS-* Web services [89]. Beside instant messaging, main request data via the topic, and publishers in the domain XMPP has been successfully deployed in the VIRTUS mid- are responsible for message distribution [219]. dleware for Internet of Things applications [62] using the DDS supports rich Quality-of-Service policies for data real-time collaboration server software OpenFire [127]. An- transmission. Interoperability between software implemen- other software that offers XMPP messaging over WebSocket tations is achieved by the RTPS [221] wire protocol. To lo- is the Kaazing WebSocket Gateway [150]. cate endpoints of peers, DDS provides dynamic discovery of publishers, subscribers, topics, and datatypes with respect to Streaming Text Oriented Messaging Protocol. The simple topics [318]. Reliable message delivery is achieved by neg- text-based wire protocol STOMP [305] is for asynchronous ative acknowledgment when data is missing [219]. Security message exchange between a client and a service or bro- extensions for DDS, e.g., encrypted transport, are still in a ker with simplicity and interoperability in mind. In the open beta state at time of writing [225]. standard of STOMP, a client and a service establish a ses- Notable software implementations are OpenDDS [218], sion and asynchronously exchange frames of type Message, RTI Connext DDS [279], PrismTech OpenSlice DDS [265], Receipt, or Error; a frame is partitioned into a command, and Twin Oaks CoreDX DDS [319]. header fields for metadata, and content of a certain MIME type. Messages are therefore dynamically typed. The proto- Apache Kafka. Developed by LinkedIn, Apache Kafka [17] col supports transactions and acknowledgments for reliable is a message broker specification and implementation for message delivery. high-throughput publish-subscribe messaging, i.e., One-to- STOMP supports either bilateral messaging, i.e., Send Many Send interaction. Kafka has an individual binary wire and Receive, or broker-based publish-subscribe as in Fig. format protocol on top of TCP, and for fault tolerance, it 16(a) for One-to-Many Send interaction. Two notable ser- supports clustering of brokers, persistent storage, and repli- vice implementations are CoilMQ [61] and, for the latest cation of messages. protocol version 1.2, Stampy [301]. On a conceptual level, Kafka distinguishes between top- ics for messages, producers that publish messages, and con- Message Queue Telemetry Transport. MQTT [125] origi- sumers that subscribe to topics. For every topic, a Kafka nates from IBM and is now an open OASIS standard [217] cluster maintains a partitioned log, where every partition for lightweight machine-to-machine messaging and Internet stores an ordered sequence of published messages. The mes- of Things applications, where bandwidth is limited. MQTT sages are kept for a configurable timespan, and partitions are is intended for broker-based publish-subscribe architectures, replicated and distributed over servers in the Kafka cluster as shown in Fig. 16(a), i.e., One-to-Many Send interaction. for fault tolerance and performance. The distributed log in An MQTT message can encapsulate binary payload up to Kafka guarantees the ordering of published and consumed 256 megabytes, but there is no notion of content type. The messages in a certain topic. For a subscribed topic, a con- participating parties therefore have to agree on allowed for- sumer maintains an offset in the message sequence to keep mats out-of-band. For reliability, the protocol offers acknowl- track of already processed ones. Through this offset, a con- edgments and retransmissions, but there is no transaction sumer can also access older messages if they are still avail- functionality. able on the cluster. 28 Harald Lampesberger

A message body is a byte sequence of a certain length RESTful Web interface, and provides STOMP over Web- and has no notion of type. Content type information there- Sockets for Web clients. fore needs to be agreed out-of-band or by using a custom protocol. An interface for Web clients to subscribe to Kafka Message queuing as a service. Message brokerage has be- over is already in an experimental state [39]. come an attractive cloud service. A broker is a critical com- ponent in a MOM architecture and needs fault-tolerance, ZeroMQ. The intelligent socket library ZeroMQ [129] aims regular maintenance, and scalability; a message queue cloud for more flexible connectivity between peers. ZeroMQ of- service can eventually reduce cost. Amazon Web Services fers several network transports, including TCP, UDP, and IP offers Simple Queue Services (SQS) [5] for transporting un- multicast, and a number of sockets types for architectural typed text-based messages up to 256 kilobytes. SQS oper- patterns. Messages are delivered to a thread- or process-local ates on a SOAP/WS-* Web service stack accessible through queue and made available through a socket. The specifica- HTTP and HTTPS bindings. tion defines the following socket types: Google’s App Engine offers Pull Queues [104] and Push Queues [105] for messaging and App Engine task distribu- – REQ and REP for bilateral Send-Receive; tion. Both queue types are accessible through a RESTful – DEALER and ROUTER for routing patterns; API and use JSON format for messages. While Pull Queues – PUB and SUB for publish-subscribe One-to-Many Send; need to be polled, Push Queues rely on webhooks for HTTP- – PUSH and PULL for workload distribution through One- based message delivery. Google has also announced Cloud to-Many Send and One-from-Many Receive; Pub/Sub [103], a broker-based publish-subscribe messaging – PAIR for asynchronous Send or Receive between two service for the App Engine, cloud apps, and Web clients. Us- sockets. ing a RESTful API, Cloud Pub/Sub distributes JSON-based messages according to topics. Subscribers can either poll for ZeroMQ has no notion of broker because it is a socket new messages or register a webhook for notification. The abstraction. However, a MOM broker could be implemented service supports guaranteed message delivery by maintain- using ZeroMQ. Messages are sequences of bytes and do not ing a queue for every subscriber, and messages are removed have a specified content type. The content type needs to be from the queue, when the client acknowledges the message. agreed on out-of-band or requires a custom protocol. Microsoft also offers two cloud-based messaging solu- An attempt to provide ZeroMQ access in Web environ- tions: Azure Queues and Service Bus Queues [179]. Azure ments is NullMQ [168]. The JavaScript library uses Web- Queues provide direct messaging between cloud services, Sockets and a modified version of STOMP to bridge Ze- and they are accessible through a RESTful interface. Mes- roMQ messages into Web browsers. sages are sequences of bytes and therefore not typed simi- ZeroRPC [69] integrates RPC on top of ZeroMQ. In- lar to Amazon SQS. Service Bus Queues offer advanced ar- formation is serialized as JSON-based MessagePack format chitectures such as publish-subscribe and routing patterns. and forwarded over ZeroMQ connections. A service inter- Windows applications and peers can access a service bus face is dynamically typed, and an ZeroRPC has been used through WCF or directly by HTTP. A BrokeredMessage in the dotCloud PaaS. in a Service Bus Queue explicitly refers to a user-specified message body content. Service Bus Queues also offer an Polyglot message brokers. A natural approach for intercon- AMQP interface [180]. necting several MOM standards is polyglot message bro- Two cloud services that offer AMQP brokerage as a ser- kerage. Three notable JMS-compliant software implemen- vice are StormMQ [306] and IronMQ [138]. CloudAMQP tations in this area are Apache ActiveMQ [6], RabbitMQ specifically offers the polyglot broker RabbitMQ as a Ser- [258], and JBoss HornetQ [120]. vice [59]. CloudMQTT [60] is another pay-per-use broker Beside features for scaling and clustering, the messag- for MQTT messaging, e.g., for complex event processing in ing core of Apache ActiveMQ, referred to as Apollo [15], Internet of Things environments. Rackspace Cloud Queues uses the OpenWire [7] wire format, but also supports stan- [267] supports publish-subscribe architectures by a HTTP- dards like AMQP, MQTT, and STOMP over WebSockets. based RESTful API in the spirit of RestMS. ActiveMQ furthermore provides a proprietary HTTP-based RESTful API for Web clients. RabbitMQ supports AMQP, STOMP, MQTT, and also 6 Discussion HTTP as transport. Messages over HTTP can be sent in three ways: a native Web management API, STOMP over Tables1,2 and3 summarize interaction patterns and prop- WebSockets, and JSON-RPC for Web browser integration. erties of discussed communication protocols and architec- HornetQ [120] is a MOM that originates from the JBoss tures. These summaries provide an overview of the state-of- . It supports AMQP, has an HTTP-based the-art for practitioners, support them in modeling of a cloud Technologies for Web and cloud service interaction: a survey 29

Table 1 Summary of interaction patterns in communication protocols. 6.1 Cloud computing aspects

Protocol Interaction patterns and properties Economies of scale, pay as you go, and service delivery over IPv4, IPv6 Bilateral Send and Receive, multilateral One-to-Many Send (IP multicast and broadcast) the Internet are three major aspects of cloud computing [90]. TCP Bilateral Send and Receive, bidirectional byte streams with Infrastructure-as-a-Service is not part of this study; however, delivery and order guarantees UDP Bilateral Send and Receive, multilateral One-to-Many Send Bitar et al. [38] review the state-of-the-art technologies in (IP multicast) provider-side cloud networking. The state-of-the-art of pro- MPTCP Bilateral Send and Receive, multihoming and multiplexing over individual TCP connections tocols and architectures for PaaS and SaaS is presented in SCTP Bilateral Send and Receive, multihoming, multiplexing, the previous sections. byte-oriented messages, optional delivery and order guar- antees While message passing has turned enterprise services QUIC Bilateral Send and Receive on top of UDP, multiplexing scalable, the custom messaging wire formats are not as reli- HTTP, HTTPS Client-to-service Send-Receive ably forwarded over the Internet as Web protocols. Beside Comet Multi-Responses from service to client, exploits HTTP per- sistent connections HTML5-enabled Web 2.0, RPC, SOAP/WS-*, and REST Reverse HTTP Client-side Receive-Send, switched roles after an HTTP for cloud services, there is a trend towards message passing Send-Receive cycle BOSH Bilateral Send and Receive, two TCP connections for on top of a Web protocol stack, e.g., RESTful APIs for mes- HTTP, hanging request for service Send SSE Multi-Responses from service to client, similar to Comet sage brokers, XMPP over HTTP or WebSocket, SOAP over WebSocket Bilateral Send and Receive, similar to TCP, established in XMPP, STOMP over WebSocket, MQTT over WebSocket, an HTTP Send-Receive cycle SPDY Client-to-service Send-Receive, optimization of HTTP Kafka over WebSocket, and NullMQ to name a few. In fact, wire format, Multi-Responses AMQP over WebSocket [215] is an ongoing standardization WebRTC Client-to-client Send and Receive, SCTP with DTLS CoAP UDP-based alternative to HTTP in the Internet of Things, effort by OASIS, so Web clients can be directly connected client-to-service Send-Receive, One-to-Many Send, One- to a message bus. XMPP already has social aspects from to-Many Send-Receive its instant messaging origin and is therefore a good candi- date for cloud messaging applications [86,121]. This trend towards Web-compatible messaging differentiates cloud ser- Table 2 Summary of interaction patterns in Web architectures. vice technology from traditional MOM. With respect to fault tolerance, Wenbing et al. [382] in- Protocol Interaction patterns and properties troduce a Low Latency Fault Tolerance (LLFT) middleware Web application HTTP or HTTPS Send-Receive interaction, Multi- Responses for audio and video streaming, push technology that specifies a messaging protocol based on UDP over IP and AJAX for asynchronous Send and Receive, dynami- multicast. Services are replicated in virtual groups, a leader cally typed Webhook Service-to-service Send between Web applications, call- is selected, and the LLFT protocol assures reliable, ordered back URLs, for Web routing patterns group-to-group message delivery. Web feed One-to-Many Send, i.e., publish-subscribe, service-to- client: by client polling or push technology, service-to- Inter-cloud communication and cloud federation also re- service: by webhooks Mashup Multiple simultaneous Web interactions quire protocols and architectures to scale, share, and syn- chronize resources or to authenticate and authorize peers. Two state-of-the-art reviews of inter-cloud computing are given by Toosi et al. [316] and Grozev and Buyya [110]. Examples for inter-cloud protocols include XMPP messag- architecture guided by interaction requirements, and there- ing [35,55] (which is also a foundation for standardized inter- fore bridge the gap between conceptual patterns and today’s cloud interoperability [36]), AMQP [35], and SOAP/WS-* protocols and architectures. Web services [50]. Furthermore, Lloret et al. [169] propose Communication protocols are primarily designed for bi- a custom TCP-based protocol for fault tolerance and load lateral interaction between two peers. Protocols for multi- distribution in a distributed inter-cloud scenario. lateral interaction, i.e., UDP over IP multicast, have appli- cations in media streaming and grid computations, but mul- ticast is typically disabled by today’s cloud providers and Cloud to device messaging. A cloud push service is con- workarounds are needed [191]. ceptually a message broker that forwards notification mes- sages from third-party services to apps on mobile devices, Multilateral interaction between peers is achieved on an e.g., . The notification client center on the mo- architectural level. A prominent architecture in the survey bile device registers at the cloud broker and typically relies is broker-based One-to-Many Send interaction, i.e., publish- on HTTP push technology to receive near-real-time notifi- subscribe. Routing patterns typically arise in low-level IP cations, often in JSON format. packet routing and high-level messaging, e.g., SOAP with Today’s prominent standards are: Google Cloud Mes- WS-Addressing, and content-based MOM filtering. saging (GCM) [102], Apple Push Notification (APN) [20], 30 Harald Lampesberger

Table 3 Summary of interaction patterns in service architectures. For example, a simple XML processing service could be implemented in three mOSAIC cloudlets. The first cloudlet Protocol Interaction patterns and properties offers a RESTful Web service, where clients can XML XML-RPC HTTP Send-Receive, dynamically typed data, and documents are forwarded to the second cloudlet. JSON-RPC Send-Receive, dynamically typed Apache Avro Send-Receive, dynamically typed When the second cloudlet is notified, it processes the XML Apache Etch TCP Send-Receive, dynamically typed Apache Thrift Send-Receive, statically typed according to the business logic and forwards the results to Protocol Buffers Send-Receive, statically typed the third cloudlet which implements a database for storage. Hessian, Burlap HTTP Send-Receive, dynamically typed The platform can then duplicate cloudlets for scaling during SOAP Send, Receive, Send-Receive, statically typed WS-Adressing Multilateral interaction and routing patterns, e.g., Relayed peak loads. Request WS-Eventing, One-to-Many Send or One-from-Many Receive, e.g., WS-Notification publish-subscribe 6.2 Observations REST Send-Receive, i.e., HTTP or CoAP, dynamically typed

JMS Transport-agnostic API, dynamically typed OpenMAMA Middleware-agnostic messaging API Multiplexing. There is a trend toward multiplexed trans- RestMS REST-based messaging API port protocols in the Web to minimize overhead when multi- JMS-compatible OpenMQ, IBM Websphere MQ, TIBCO Enterprise Mes- ple resources are requested in parallel by a Web client, e.g., sage Service SPDY and the upcoming HTTP/2. SPDY is already available Proprietary TIBCO Rendezvous, Oracle Tuxedo, Terracotta Universal Messaging in and effectively used as transport mech- MSMQ Peer-to-peer, Send, Receive, One-to-Many Send (using net- work multicast), broker-based: SQL Server Service Broker anism, when Google cloud services are consumed. Multi- plexing can also contribute to service-oriented architectures AMQP Broker-like exchanges, Send, Receive, One-to-Many Send, dynamically typed in cloud backend infrastructure, e.g., RPC or MOM, when XMPP Broker-based Send and Receive; with extensions One-to- Many Send, i.e., publish-subscribe, untyped or dynamically interactions between two peers are highly parallel, e.g., the typed Mux protocol in Twitter’s Finagle [320] RPC framework. STOMP Send and Receive, broker-based One-to-Many Send, i.e., publish-subscribe, dynamically typed MQTT Broker-based One-to-Many Send, untyped DDS Peer-to-peer One-to-Many Send, i.e., publish-subscribe, Multihoming. Mobile devices are still a growing market, statically typed and an increasing number of devices is simultaneously con- Apache Kafka Broker-based One-to-Many Send, i.e., publish-subscribe, untyped nected to multiple networks, e.g., Wi-Fi and 3G/4G net- ZeroMQ Untyped socket abstraction, various patterns works. Multihoming protocols like MPTCP already exploit this connectivity in Apple devices to increase client-side ac- cess quality for the Apple Siri service [19]. Now that im- Windows Push Notification Services (WNS) [187], Black- plementations and libraries are available on a popular plat- berry Push Service [40], and Nokia Notifications [178]. form, multihoming will eventually become mainstream. Ex- perimental Linux kernels with MPTCP support for Android devices do already exist [321]. Client-cloud interaction examples. The first cloud example concerns management of resources. The Open Cloud Com- Pervasive encryption. Middleboxes for various networking puting Interface (OCCI) [230] is a standardization attempt applications, e.g., firewalls or traffic shapers, monitor com- toward a unified Web-compatible RESTful API in particu- munication all over the Internet, and they often rely on DPI. lar for IaaS. For example, the OpenStack [233] IaaS cloud Modern transport protocols such as MPTCP and QUIC, but platform supports OCCI to deploy or scale virtual machines, also SPDY proclaim pervasive encryption, so middleboxes change network addresses, or allocate storage. cannot tamper with network interaction. It is safe to assume The second example is the Open-Source API and Plat- that network traffic encryption will flourish in the future, and form for Multiple Clouds (mOSAIC) [255] that also im- DPI-based monitoring is eventually affected. plements OCCI. The mOSAIC software platform provides Furthermore, an observation in this study is an increas- a vendor-neutral way of running so-called cloudlets, i.e., ing distrust in X.509 public key infrastructure. Any certifi- event-driven and stateless components that implement ap- cate authority, trusted by a Web client, can issue a trusted plication functionality. Core components of the mOSAIC cryptographic certificate for any service FQDN. Certificate platform are responsible for scheduling, monitoring, scaling, authorities are typically shipped with software, so the trust and deployment of cloudlets, and the platform provides an relationship is hardly reviewed. A malign authority can is- asynchronous message bus, e.g., AMQP or Amazon SQS, so sue forged X.509 certificates for man-in-the-middle attacks cloudlets can interact. Furthermore, a cloudlet implements in network traffic monitoring [122]. An observed trend is connectors and drivers for communication technologies to certificate pinning [244], where a client gets access to ad- interact with clients and services. ditional information to verify an X.509 service certificate, Technologies for Web and cloud service interaction: a survey 31 e.g., a fingerprint of the expected public key or a certificate- 2.0 content needs to be stored and forwarded, and a lot of ef- specific restrictions on authorities. These techniques are al- fort has been invested to deliver media in time, e.g., Content ready put to use today, e.g., in mobile phone apps as a pro- Delivery Networks (CDNs). Pay-per-use and flexible scala- tection against reverse engineering [242] or as a security bility in cloud computing industrialize this process, but gov- mechanism in the Google Chrome browser [309]. ernance of data, trust, and cloud vendor lock-in are still un- resolved problems for users. Importance of DNS. The majority of architectures in this JavaScript and HTML5 turn Web browsers into virtual article rely on DNS as an abstraction layer for locating ser- machines of the Web, and WebRTC enables direct, asyn- vice endpoints, i.e., host names. DNS SRV records even chronous interaction between them. A potential application allow dynamic service discovery [58]. The importance of is a new era of peer-to-peer networking and code mobil- DNS security aspects is well known, and mainstream adap- ity, where clients can seamlessly become service providers, tion of DNSSEC is therefore expected [112]. and cloud services merely participate for discovery and sig- naling between clients. Existing MOM standards could be Correct types. Dynamically typed interfaces offer great adapted to provide a messaging infrastructure over WebRTC flexibility, but rely on correctness of the content type de- as transport mechanism. An example for today’s WebRTC scriptor of a message, so a correct module for parsing is cho- usage is PeerCDN [254], a distributed peer-to-peer cache as sen during runtime. MIME types can be ambiguous because an alternative to costly CDN infrastructure. of implicit subtype relations, e.g., every content that satisfies application/xml also satisfies MIME type text/plain Monitoring implications. From an interaction aspect, DPI but semantics are different. Nevertheless, Web technology network traffic monitoring [32] is a common security policy relies on MIME types as identifiers, and incorrect type in- decision point, e.g., next-generation firewalls, intrusion de- formation can severely affect function and security. tection and prevention systems, data loss prevention, breach Two problems in Web browsers with respect to type cor- detection, censorship, or traffic shaping. The survey indi- rectness have been observed. If the Content-Type is miss- cates the following implications about DPI systems: ing in an HTTP response, a Web browser tolerates the er- ror and tries to guess the MIME type using heuristics, i.e., – To analyze encrypted network traffic, a DPI system has content sniffing [29]. Furthermore, HTML and XHTML al- to break the encryption, which is a hard problem or re- low to define an expected MIME type as attribute of embed quires misuse of X.509 public key infrastructure to or object markup tags. There is a type conflict if the ex- certificates. Otherwise, only metadata about an interac- pected type and the HTTP response content type are not tion are available for policy decision making. the same, and the browser is responsible for resolving the – Assuming that a DPI system is capable of breaking the conflict. Type heuristics and conflicting types have already encryption using a man-in-the-middle-attack by misus- been exploited to attack Web browsers and undermine con- ing an authority to forge certificates, certificate pinning tent policies [29,171]. Correctness of types is therefore es- can still prevent communication, even when the misused sential for secure composition of services. certificate authority is trusted by the client. – Furthermore, a DPI system is bound to some physical Polyglot messaging. The large number of messaging stan- domain. Multihoming communication utilizes all avail- dards for MOM complicates access from Web clients. Due able physical paths, where eventually one path is invisi- to varying application profiles in MOM, e.g., Internet of ble to the DPI system, e.g., a path over 3G/4G networks. Things or enterprise service bus, the diversity of technolo- So, the monitor only has a limited view of the communi- gies for MOM will likely stay. Nevertheless, there is a trend cation which impairs decision making, even when based toward messaging in Web and cloud clients for near-real- on metadata or network traffic characteristics. time communication, so an increasing number of software implementations add Web-compatible interfaces like SOAP, A conclusion is that future security systems need to be JSON-RPC, RestMS, or individual RESTful interfaces. The situated directly on the client side or service side at com- survey indicates that implementations tend to offer adapters munication endpoints or as a component in the client or ser- for Web clients using WebSockets. So, Web clients can be vice. Otherwise, visibility of communication is not guaran- connected to messaging infrastructure using, e.g., AMQP, teed with upcoming communication protocols. STOMP, MQTT, and XMPP.

Client-to-client messaging. WebRTC has the potential to 7 Conclusion fundamentally change the Web experience. Today, Web in- teraction takes place between a Web client and a Web appli- The study presents the state-of-the-art in technologies for cation or service. A growing amount of user-provided Web interaction between clients and services in Web and cloud 32 Harald Lampesberger environments. As clients and services are distributed, com- 6. Apache Software Foundation: Apache ActiveMQ (2011). URL munication over networks is necessary for interaction. The http://activemq.apache.org/. Accessed 2014-02-21 survey distinguishes languages, protocols, and architectures: 7. Apache Software Foundation: OpenWire Version 2 Specification (2011). URL http://activemq.apache.org/openwire- Languages encapsulate information in a transportable for- version-2-specification.html. Accessed 2014-02-20 mat; protocols specify communication channel languages 8. Apache Software Foundation: Apache Abdera: An Open Source and rules of engagement for low-level interaction; and ar- Atom Implementation (2012). URL ://abdera. chitectures integrate languages, protocols, and service inter- apache.org/. Accessed 2014-05-08 9. Apache Software Foundation: Apache Axis2/Java (2012). URL action patterns into blueprints for service delivery. http://axis.apache.org/axis2/java/core/. Accessed Architectures are approached in two different directions. 2014-03-28 The Web-oriented view highlights the evolution of the Web 10. Apache Software Foundation: Apache Thrift (2012). URL and technological advancements, e.g., AJAX, HTML5, syn- http://thrift.apache.org/. Accessed 2014-02-20 11. Apache Software Foundation: Apache Etch (2013). URL http: dication, and mashups. The service-oriented view highlights //etch.apache.org/. Accessed 2014-02-21 architectures and technologies for services originating from 12. Apache Software Foundation: Apache Qpid (2013). URL enterprise environments. The survey indicates that technolo- https://qpid.apache.org/. Accessed 2014-07-21 gies in both views are more and more converging by turning 13. Apache Software Foundation: Apache Avro 1.7.6 Specifica- tion (2014). URL http://avro.apache.org/docs/1.7.6/ scalable enterprise architectures Web-compatible. spec.html. Accessed 2014-02-21 Languages and protocols that originate from Web appli- 14. Apache Software Foundation: Apache CXF: An Open-Source cations, e.g., HTTP, are becoming an integral part in service Services Framework (2014). URL http://cxf.apache.org/. and cloud technology because these protocols are supported Accessed 2014-03-28 15. Apache Software Foundation: Apollo – ActiveMQ’s next gener- on a wide range of platforms and correctly forwarded over ation of messaging (2014). URL http://activemq.apache. the Internet. On the other hand, architectures for large-scale org/apollo/. Accessed 2014-07-24 distributed systems, e.g., RPC or message passing, more and 16. Apache Software Foundation: Hadoop (2014). URL http:// more influence how Web applications are implemented and hadoop.apache.org/. Accessed 2014-07-10 composed, e.g., mashups, to fully utilize the capabilities of 17. Apache Software Foundation: Kafka (2014). URL http:// kafka.apache.org/. Accessed 2014-07-15 an underlying cloud infrastructure. Especially new technolo- 18. Apple: Property list specification (2012). URL http://www. gies like WebSocket and WebRTC have a potential to main- apple.com/DTDs/PropertyList-1.0.dtd. Accessed 2014- stream sophisticated MOM architectures in the Web. Fur- 02-21 thermore, upcoming protocols and architectures will have 19. Apple: iOS: Multipath TCP Support in iOS 7 (2014). URL http://support.apple.com/kb/HT5977. Accessed 2014- an impact on network monitoring, especially on DPI-based 05-22 systems. For the future, alternatives like client- and service- 20. Apple: Local and push notifications (2014). URL https:// centric monitoring approaches need to be considered. developer.apple.com/notifications/. Accessed 2014- 12-05 21. Arends, R., Austein, R., Larson, M., Massey, D., Rose, S.: Acknowledgements This research has been supported by the Chris- DNS Security Introduction and Requirements. RFC 4033 (Pro- tian Doppler Society. The author thanks the anonymous reviewers, Rox- posed Standard) (2005). URL http://www.ietf.org/rfc/ ana Holom, Tania Nemes, Mircea Boris Vleju, and Philipp Winter for rfc4033.txt. Updated by RFCs 6014, 6840 the valuable feedback to improve this work. 22. Arends, R., Austein, R., Larson, M., Massey, D., Rose, S.: Pro- tocol Modifications for the DNS Security Extensions. RFC 4035 (Proposed Standard) (2005). URL http://www.ietf.org/ rfc/rfc4035.txt. Updated by RFCs 4470, 6014, 6840 References 23. Arends, R., Austein, R., Larson, M., Massey, D., Rose, S.: Re- source Records for the DNS Security Extensions. RFC 4034 1. van der Aalst, W.M.P., Mooij, A.J., Stahl, C., Wolf, K.: Ser- (Proposed Standard) (2005). URL http://www.ietf.org/ vice interaction: Patterns, formalization, and analysis. In: Formal rfc/rfc4034.txt. Updated by RFCs 4470, 6014, 6840, 6944 Methods for Web Services, Lecture Notes in Computer Science, 24. Armbrust, M., Fox, A., Griffith, R., Joseph, A.D., Katz, R., Kon- vol. 5569, pp. 42–88. Springer Berlin Heidelberg (2009) winski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I., Zaharia, 2. Adams, D.: XEP-0030: Service Discovery (2011). URL http: M.: A view of cloud computing. Communications of the ACM //.org/extensions/xep-0009.html. Accessed 2014- 53(4), 50–58 (2010) 07-23 25. Barros, A., Dumas, M., ter Hofstede, A.H.: Service interaction 3. Alinone, A.: 10 years of push technology, comet, and websockets patterns. In: Business Process Management, Lecture Notes in (2011). URL http://cometdaily.com/2011/07/06/push- Computer Science, vol. 3649, pp. 302–318. Springer Berlin Hei- technology-comet-and-websockets-10-years-of- delberg (2005) history-from-lightstreamers-perspective/. Accessed 26. Barros, A., Dumas, M., ter Hofstede, A.H.: Service interaction 2014-02-17 patterns: Towards a reference framework for service-based busi- 4. Alonso, G., Casati, F., Kuno, H.A., Machiraj, .: Web Services - ness process interconnection. Tech. Rep. FIT-TR-2005-02, Fac- Concepts, Architectures and Applications. Springer (2004) ulty of IT, Queensland University of Technology (2005) 5. Amazon Web Services: Amazon Simple Queue Service (Amazon 27. Barth, A.: HTTP State Management Mechanism. RFC 6265 SQS) (2013). URL http://aws.amazon.com/sqs/. Accessed (Proposed Standard) (2011). URL http://www.ietf.org/ 2014-02-21 rfc/rfc6265.txt Technologies for Web and cloud service interaction: a survey 33

28. Barth, A.: The Web Origin Concept. RFC 6454 (Proposed Stan- 47. Bray, T.: The JavaScript Object Notation (JSON) Data Inter- dard) (2011). URL http://www.ietf.org/rfc/rfc6454. change Format. RFC 7159 (Proposed Standard) (2014). URL txt http://www.ietf.org/rfc/rfc7159.txt 29. Barth, A., Caballero, J., Song, D.: Secure content sniffing for 48. Bósa, K.: Formal modeling of mobile computing systems based web browsers, or how to stop papers from reviewing themselves. on ambient abstract state machines. In: Semantics in Data In: 30th IEEE Symposium on Security and Privacy, S&P’09, pp. and Knowledge Bases, Lecture Notes in Computer Science, vol. 360–371. IEEE (2009) 7693, pp. 18–49. Springer Berlin Heidelberg (2013) 30. Belshe, M., Peon, R., Thomson, M.: Hypertext Transfer Proto- 49. BSON: Version 1.0 specification (2013). URL http:// col version 2 (Internet-Draft) (2014). URL https://http2. bsonspec.org/. Accessed 2014-02-21 .io/http2-spec/. Accessed 2014-04-08 50. Buyya, R., Ranjan, R., Calheiros, R.N.: Intercloud: Utility- 31. Ben-Kiki, ., Evans, C., döt Net, I.: YAML Ain’t Markup Lan- oriented federation of cloud computing environments for scaling guage (YAML) Version 1.2 (2009). URL http://yaml.org/ of application services. In: Algorithms and Architectures for Par- spec/1.2/spec.html. Accessed 2014-02-20 allel Processing, Lecture Notes in Computer Science, vol. 6081, 32. Bendrath, R., Mueller, M.: The end of the net as we know it? pp. 13–31. Springer Berlin Heidelberg (2010) deep packet inspection and internet governance. New Media & 51. Candle App Platform: Candle markup reference (2013). URL Society 13(7), 1142–1160 (2011) http://www.candlescript.org/doc/candle-markup- 33. Beraka, M., Mathkour, H., Gannouni, S., Hashimi, H.: Applica- reference.htm. Accessed 2014-02-21 tions of different web service composition standards. In: 2012 In- 52. Carpenter, B., Brim, S.: Middleboxes: Taxonomy and Issues. ternational Conference on Cloud and Service Computing (CSC), RFC 3234 (Informational) (2002). URL http://www.ietf. pp. 56–63 (2012) org/rfc/rfc3234.txt 34. Berners-Lee, T., Fielding, R., Masinter, .: Uniform Resource 53. Caucho Technology, Inc.: Burlap 1.0 specification (2002). Identifier (URI): Generic Syntax. RFC 3986 (INTERNET URL http://hessian.caucho.com/doc/burlap-1.0- STANDARD) (2005). URL http://www.ietf.org/rfc/ spec.xtp. Accessed 2014-02-21 rfc3986.txt. Updated by RFCs 6874, 7320 54. Caucho Technology, Inc.: Hessian binary web service protocol 35. Bernstein, D., Ludvigson, E., Sankar, K., Diamond, S., Mor- (2012). URL http://hessian.caucho.com. Accessed 2014- row, M.: Blueprint for the intercloud - protocols and formats for 02-21 cloud computing interoperability. In: 4th International Confer- 55. Celesti, A., Tusa, F., Villari, M., Puliafito, A.: How to enhance ence on Internet and Web Applications and Services, ICIW’09. cloud architectures to enable cross-federation. In: 3rd Interna- IEEE (2009) tional Conference on Cloud Computing, CLOUD’10, pp. 337– 345. IEEE (2010) 36. Bernstein, D., Vij, D.K.: Draft Standard for Intercloud Inter- 56. Chelemen, R.M.: Modeling a web application for cloud content operability and Federation (SIIF). Tech. Rep. P2302/D0.2, adaptation with asms. In: International Conference on Cloud IEEE (2012). URL http://www.intercloudtestbed.org/ Computing and Big Data, CloudCom-Asia’13, pp. 44–51. IEEE uploads/2/1/3/9/21396364/intercloud_p2302_draft_ (2013) 0.2.pdf. Accessed 2015-01-16 57. Cheng, Y., Chu, J., Radhakrishnan, S., Jain, A.: TCP Fast Open 37. Birrell, A.D., Nelson, B.J.: Implementing remote procedure calls. (2014). URL https://tools.ietf.org/html/draft- ACM Trans. Comput. Syst. 2(1), 39–59 (1984) ietf-tcpm-fastopen-06. Accessed 2014-05-23 38. Bitar, N., Gringeri, S., Xia, T.: Technologies and protocols for 58. Cheshire, S., Krochmal, M.: DNS-Based Service Discovery. data center and cloud networking. IEEE Communications Mag- RFC 6763 (Proposed Standard) (2013). URL http://www. azine 51(9), 24–31 (2013) ietf.org/rfc/rfc6763.txt 39. Black, B.: kafka- (2014). URL https://github. 59. CloudAMQP: RabbitMQ as a Service (2014). URL http:// com/b/kafka-websocket. Accessed 2014-08-03 www.cloudamqp.com. Accessed 2014-07-21 40. BlackBerry Developer: Push Service (2014). URL http:// 60. CloudMQTT: Hosted broker for the Internet of Things (2014). developer.blackberry.com/services/push/. Accessed URL http://www.cloudmqtt.com. Accessed 2014-07-25 2014-12-05 61. CoilMQ: Lightweight Python STOMP message broker (2012). 41. Bonaventure, O., Handley, M., Raiciu, C.: An overview of mul- URL https://github.com/hozn/coilmq/. Accessed 2014- tipath tcp. USENIX login; (2012) 07-24 42. Bonetta, D., Peternier, A., Pautasso, C., Binder, W.: S: A script- 62. Conzon, D., Bolognesi, T., Brizzi, P., Lotito, A., Tomasi, R., Spir- ing language for high-performance restful web services. In: Pro- ito, M.: The virtus middleware: An xmpp based architecture for ceedings of the 17th ACM SIGPLAN Symposium on Principles secure iot communications. In: 21st International Conference on and Practice of Parallel Programming, PPoPP’12, pp. 97–106. Computer Communications and Networks, ICCCN’12, pp. 1–6 ACM (2012) (2012) 43. Bormann, C., Hoffman, P.: Concise Binary Object Representa- 63. Cormode, G., Krishnamurthy, B.: Key differences between tion (CBOR). RFC 7049 (Proposed Standard) (2013). URL web 1.0 and web 2.0. First Monday 13(6) (2008). URL http://www.ietf.org/rfc/rfc7049.txt http://firstmonday.org/ojs/index.php/fm/article/ 44. Bósa, K.: An ambient asm model for client-to-client interac- view/2125 tion via cloud computing. In: Proceedings of the 8th Inter- 64. Curry, E.: Message-oriented middleware. In: Q.H. Mahmoud national Conference on Software and Data Technologies (IC- (ed.) Middleware for Communications. John Wiley & Sons, Ltd, SOFT), Reykjavik, Iceland. SciTePress (2013). URL http: Chichester, UK (2005) //www.icsoft.org/. (Best Paper Award) 65. Daboo, C.: CardDAV: vCard Extensions to Web Distributed Au- 45. Bova, T., Krivoruchka, T.: Reliable UDP Protocol (1999). thoring and Versioning (WebDAV). RFC 6352 (Proposed Stan- URL https://datatracker.ietf.org/doc/draft- dard) (2011). URL http://www.ietf.org/rfc/rfc6352. lentczner-rhttp/. Accessed 2014-28-05 txt. Updated by RFC 6764 46. Braden, R.: Requirements for Internet Hosts - Communica- 66. Daboo, C., Desruisseaux, B., Dusseault, L.: Calendaring Ex- tion Layers. RFC 1122 (INTERNET STANDARD) (1989). tensions to WebDAV (CalDAV). RFC 4791 (Proposed Stan- URL http://www.ietf.org/rfc/rfc1122.txt. Updated dard) (2007). URL http://www.ietf.org/rfc/rfc4791. by RFCs 1349, 4379, 5884, 6093, 6298, 6633, 6864 txt. Updated by RFCs 5689, 6638, 6764 34 Harald Lampesberger

67. Deering, S., Hinden, R.: Internet Protocol, Version 6 (IPv6) Spec- on Mobile Cloud Computing and Services, MCS’13, pp. 17–24. ification. RFC 2460 (Draft Standard) (1998). URL http:// ACM (2013) www.ietf.org/rfc/rfc2460.txt. Updated by RFCs 5095, 87. Ford, A., Raiciu, C., Handley, M., Bonaventure, O.: TCP Exten- 5722, 5871, 6437, 6564, 6935, 6946, 7045, 7112 sions for Multipath Operation with Multiple Addresses. RFC 68. Dierks, T., Rescorla, E.: The (TLS) 6824 (Experimental) (2013). URL http://www.ietf.org/ Protocol Version 1.2. RFC 5246 (Proposed Standard) (2008). rfc/rfc6824.txt URL http://www.ietf.org/rfc/rfc5246.txt. Updated 88. Ford, B.: Structured streams: A new transport abstraction. SIG- by RFCs 5746, 5878, 6176 COMM Comput. Commun. Rev. 37(4), 361–372 (2007) 69. dotCloud: ZeroRPC (2013). URL http://zerorpc. 89. Forno, F., Saint-Andre, P.: XEP-0072: SOAP Over XMPP dotcloud.com/. Accessed 2014-02-19 (2005). URL http://xmpp.org/extensions/xep-0072. 70. Dubuisson, O., Fouquart, P.: ASN.1: Communication Between html. Accessed 2014-07-23 Heterogeneous Systems. Morgan Kaufmann Publishers Inc., San 90. Foster, I., Zhao, Y., Raicu, I., Lu, S.: Cloud computing and grid Francisco, CA, USA (2001) computing 360-degree compared. In: Grid Computing Environ- 71. Dusseault, L.: HTTP Extensions for Web Distributed Author- ments Workshop, GCE’08, pp. 1–10. IEEE (2008) ing and Versioning (WebDAV). RFC 4918 (Proposed Stan- 91. Freed, N., Borenstein, N.: Multipurpose Internet Mail Extensions dard) (2007). URL http://www.ietf.org/rfc/rfc4918. (MIME) Part One: Format of Internet Message Bodies. RFC txt. Updated by RFC 5689 2045 (Draft Standard) (1996). URL http://www.ietf.org/ 72. ECMA International: Standard ECMA-262 – ECMAScript rfc/rfc2045.txt. Updated by RFCs 2184, 2231, 5335, 6532 Language Specification (2011). URL http://www.ecma- 92. Freed, N., Borenstein, N.: Multipurpose Internet Mail Exten- international.org/publications/standards/Ecma- sions (MIME) Part Two: Media Types. RFC 2046 (Draft Stan- 262.htm. Accessed 2014-02-21 dard) (1996). URL http://www.ietf.org/rfc/rfc2046. 73. Eddy, W.: TCP SYN Flooding Attacks and Common Mitigations. txt. Updated by RFCs 2646, 3798, 5147, 6657 RFC 4987 (Informational) (2007). URL http://www.ietf. 93. Freier, A., Karlton, P., Kocher, P.: The Secure Sockets Layer org/rfc/rfc4987.txt (SSL) Protocol Version 3.0. RFC 6101 (Historic) (2011). URL 74. Endres-Niggemeyer, B.: The mashup ecosystem. In: Semantic http://www.ietf.org/rfc/rfc6101.txt Mashups, pp. 1–51. Springer Berlin Heidelberg, Berlin, Heidel- 94. Furuhashi, S.: MessagePack (2013). URL http://msgpack. berg (2013) org/. Accessed 2014-02-21 75. Fette, I., Melnikov, A.: The WebSocket Protocol. RFC 6455 95. Galiegue, F., Zyp, K., Court, G.: JSON Schema: core definitions (Proposed Standard) (2011). URL http://www.ietf.org/ and terminology (2013). URL https://datatracker.ietf. rfc/rfc6455.txt org/doc/draft-zyp-json-schema/. Accessed 2014-06-18 76. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 96. Garnock-Jones, T.: Reverse HTTP (2010). URL http:// L., Leach, P., Berners-Lee, T.: Hypertext Transfer Protocol – reversehttp.net/reverse-http-spec.html. Accessed HTTP/1.1. RFC 2616 (Draft Standard) (1999). URL http:// 2014-03-04 www.ietf.org/rfc/rfc2616.txt. Obsoleted by RFCs 7230, 97. Garrett, J.J.: AJAX (2005). URL http://www. 7231, 7232, 7233, 7234, 7235, updated by RFCs 2817, 5785, adaptivepath.com/ideas/ajax-new-approach-web- 6266, 6585 applications. Accessed 2013-03-27 77. Fielding, R., Lafon, Y., Reschke, J.: Hypertext Transfer Protocol 98. GlassFish Project: (2014). URL https: (HTTP/1.1): Range Requests. RFC 7233 (Proposed Standard) //mq.java.net/. Accessed 2014-02-19 (2014). URL http://www.ietf.org/rfc/rfc7233.txt 78. Fielding, R., Nottingham, M., Reschke, J.: Hypertext Transfer 99. Google Developers: Protocol Buffers (2012). URL https:// Protocol (HTTP/1.1): Caching. RFC 7234 (Proposed Standard) developers.google.com/protocol-buffers/. Accessed (2014). URL http://www.ietf.org/rfc/rfc7234.txt 2014-02-20 79. Fielding, R., Reschke, J.: Hypertext Transfer Protocol 100. Google Developers: Gadgets API (2013). URL https:// (HTTP/1.1): Authentication. RFC 7235 (Proposed Standard) developers.google.com/gadgets/. Accessed 2014-07-08 (2014). URL http://www.ietf.org/rfc/rfc7235.txt 101. Google Developers: Google APIs Discovery Service (2014). 80. Fielding, R., Reschke, J.: Hypertext Transfer Protocol URL https://developers.google.com/discovery/. Ac- (HTTP/1.1): Conditional Requests. RFC 7232 (Proposed cessed 2014-07-18 Standard) (2014). URL http://www.ietf.org/rfc/ 102. Google Developers: for Android rfc7232.txt (2014). URL https://developer.android.com/google/ 81. Fielding, R., Reschke, J.: Hypertext Transfer Protocol gcm/index.html. Accessed 2014-12-05 (HTTP/1.1): Message Syntax and Routing. RFC 7230 103. Google Developers: Google Cloud Pub/Sub (2014). URL (Proposed Standard) (2014). URL http://www.ietf.org/ https://developers.google.com/pubsub/overview. rfc/rfc7230.txt Accessed 2014-08-07 82. Fielding, R., Reschke, J.: Hypertext Transfer Protocol 104. Google Developers: Using Pull Queues in Java (2014). URL (HTTP/1.1): Semantics and Content. RFC 7231 (Proposed https://developers.google.com/appengine/docs/ Standard) (2014). URL http://www.ietf.org/rfc/ java/taskqueue/overview-pull. Accessed 2014-08-07 rfc7231.txt 105. Google Developers: Using Push Queues in Java (2014). URL 83. Fielding, R.T.: REST: Architectural styles and the design of https://developers.google.com/appengine/docs/ network-based software architectures. Phd thesis, University of java/taskqueue/overview-push. Accessed 2014-08-07 California, Irvine (2000) 106. Google Inc.: WebRTC (2012). URL http://www.webrtc. 84. Fielding, R.T.: Rest apis must be hypertext-driven (2008). URL org/. Accessed 2014-02-17 http://roy.gbiv.com/untangled/2008/rest-apis- 107. Gottschalk, K., Graham, S., Kreger, H., Snell, J.: Introduction to must-be-hypertext-driven. Accessed 2014-07-18 web services architecture. IBM Systems Journal 41(2), 170–177 85. Fielding, R.T., Taylor, R.N.: Principled design of the modern web (2002) architecture. ACM Trans. Internet Technol. 2(2), 115–150 (2002) 108. Goubard, A., Uijthof, L.: XINS – XML Interface for Network 86. Flores, H., Srirama, S.: Mobile cloud messaging supported by Services (1999). URL http://xins.sourceforge.net/. Ac- xmpp primitives. In: Proceeding of the Fourth ACM Workshop cessed 2014-03-03 Technologies for Web and cloud service interaction: a survey 35

109. Gregorio, J., de hOra, B.: The Atom Publishing Protocol. RFC 132. International Organization for Standardization: Website (2014). 5023 (Proposed Standard) (2007). URL http://www.ietf. URL http://www.iso.org/. Accessed 2014-07-01 org/rfc/rfc5023.txt 133. International Telecommunication Union: Website (2014). URL 110. Grozev, N., Buyya, R.: Inter-cloud architectures and application http://www.itu.int/. Accessed 2014-07-01 brokering: taxonomy and survey. Software: Practice and Experi- 134. Internet Assigned Numbers Authority: Website (2014). URL ence 44(3), 369–390 (2014) https://www.iana.org/. Accessed 2014-07-01 111. Grune, D.: Parsing Techniques: A Practical Guide, 2nd edn. 135. Internet Corporation for Assigned Names and Numbers: Website Springer Publishing Company, Incorporated (2010) (2014). URL https://www.icann.org. Accessed 2014-07-01 112. Herzberg, A., Shulman, H.: Dnssec: Security and availability 136. Internet Engineering Task Force: Website (2014). URL http: challenges. In: 2013 IEEE Conference on Communications and //www.ietf.org/. Accessed 2014-07-01 Network Security, pp. 365–366 (2013) 137. Ippolito, B.: Remote JSON - JSONP (2005). URL 113. Hildebrand, J., Millard, P., Eatmon, R., Saint-Andre, P.: http://bob.ippoli.to/archives/2005/12/05/remote- XEP-0009: Jabber-RPC (2008). URL http://xmpp.org/ json-jsonp/. Accessed 2014-07-01 extensions/xep-0030.html. Accessed 2014-07-23 138. Iron.io: IronMQ (2014). URL http://www.iron.io/mq. Ac- 114. Hildebrand, J., Saint-Andre, P.: XEP-0033: Extended Stanza Ad- cessed 2014-02-20 dressing (2004). URL http://xmpp.org/extensions/xep- 139. ISO: ISO/IEC 23001-1:2006 Information technology – MPEG 0033.html. Accessed 2014-07-23 systems technologies – Part 1: Binary MPEG format for XML 115. HiveMQ: Enterprise Grade MQTT Broker (2014). URL http: (2006). URL http://www.iso.org/iso/iso_catalogue/ //www.hivemq.com/. Accessed 2014-07-22 catalogue_tc/catalogue_detail.htm?csnumber=35417. 116. Hodges, J., Jackson, C., Barth, A.: HTTP Strict Transport Se- Accessed 2014-06-16 curity (HSTS). RFC 6797 (Proposed Standard) (2012). URL 140. ISO: ISO/IEC 19464:2014 Information technology – Advanced http://www.ietf.org/rfc/rfc6797.txt Message Queuing Protocol (AMQP) v1.0 specification (2014). 117. Hoehrmann, B.: Scripting Media Types. RFC 4329 (Informa- URL http://www.iso.org/iso/home/store/catalogue_ tional) (2006). URL http://www.ietf.org/rfc/rfc4329. tc/catalogue_detail.htm?csnumber=64955. Accessed txt 2014-08-06 118. Hohpe, G., Woolf, B.: Enterprise Integration Patterns: Designing, 141. ITU: X.891: Information technology - Generic applications of Building, and Deploying Messaging Solutions. Addison-Wesley ASN.1: Fast infoset (2005). URL http://www.itu.int/rec/ Longman Publishing Co., Inc., Boston, MA, USA (2003) T-REC-X.891-200505-I/en. Accessed 2014-06-16 142. Java Community Process: JSR 101: Java APIs for XML based 119. Hopcroft, J.E., Ullman, J.D.: Introduction to Automata Theory, RPC (2003). URL https://jcp.org/en/jsr/detail?id= Languages and Computation, Second Edition. Addison-Wesley 101. Accessed 2014-03-28 (2000) 143. Java Community Process: JSR 67: JavaTM APIs for XML Mes- 120. HornetQ: What is HornetQ? (2013). URL http://hornetq. saging 1.0 (2006). URL https://jcp.org/en/jsr/detail? jboss.org/. Accessed 2014-07-24 id=67. Accessed 2014-03-28 121. Hornsby, A., Walsh, R.: From instant messaging to cloud com- 144. Java Community Process: JSR 224: Java API for XML-Based puting, an xmpp review. In: IEEE 14th International Symposium Web Services (JAX-WS) 2.0 (2011). URL https://jcp.org/ on Consumer Electronics, ISCE’10, pp. 1–6. IEEE (2010) en/jsr/detail?id=224. Accessed 2014-03-28 122. Huang, L.S., Rice, A., Ellingsen, E., Jackson, C.: Analyzing 145. Java Community Process: JSR 339: JAX-RS 2.0: The Java API forged ssl certificates in the wild. In: IEEE Symposium on Secu- for RESTful Web Services (2013). URL https://jcp.org/ rity and Privacy, S&P’14. IEEE (2014) en/jsr/detail?id=339. Accessed 2014-03-28 123. IBM: WebSphere JAX-WS runtime environment (2014). 146. java.net: GlassFish Metro (2014). URL https://metro.java. URL http://pic.dhe.ibm.com/infocenter/rsawshlp/ net/discover/. Accessed 2014-03-28 v7r5m0/index.jsp?topic=%2Fcom.ibm.webservice. 147. JBoss Community: JBoss Web Services (2014). URL https: jaxws.creation.doc%2Ftopics%2Fcjaxwsruntime.html. //www.jboss.org/jbossws. Accessed 2014-03-28 Accessed 2014-03-28 148. Josefsson, S.: The Base16, Base32, and Base64 Data Encod- 124. IBM: WebSphere MQ (2014). URL http://www-03.ibm. ings. RFC 4648 (Proposed Standard) (2006). URL http: com/software/products/en/websphere-mq. Accessed //www.ietf.org/rfc/rfc4648.txt 2014-07-22 149. Joyent, Inc.: Node.js (2014). URL http://nodejs.org/. Ac- 125. IBM Developer Networks: MQ Telemetry Transport (MQTT) cessed 2014-06-20 V3.1 Protocol Specification (2010). URL http://www.ibm. 150. Kaazing: WebSocket Gateway - XMPP (2014). URL com/developerworks/webservices/library/ws-/. http://kaazing.com/products/editions/kaazing- Accessed 2014-02-20 websocket-gateway-xmpp/. Accessed 2014-07-23 126. IETF HTTPbis WG: HTTP/2 Frequently Asked Questions 151. Khare, R., Lawrence, S.: Upgrading to TLS Within HTTP/1.1. (2014). URL http://http2.github.io/faq/. Accessed RFC 2817 (Proposed Standard) (2000). URL http://www. 2014-02-28 ietf.org/rfc/rfc2817.txt. Updated by RFCs 7230, 7231 127. ignite realtime: Openfire (2014). URL http://www. 152. Khronos Group: WebGL Specification Version 1.0.2 (2013). igniterealtime.org/projects/openfire/. Accessed URL https://www.khronos.org/registry/webgl/ 2014-07-23 specs/1.0/. Accessed 2014-03-28 128. iMatix Corporation: OpenAMQ (2009). URL http://www. 153. Khronos Group: WebCL Specification Version 1.0 (2014). openamq.org/. Accessed 2014-02-21 URL http://www.khronos.org/registry/webcl/specs/ 129. iMatix Corporation: /0MQ(2013). URL http://www.zeromq. 1.0.0/. Accessed 2014-03-28 org/. Accessed 2014-02-19 154. Kiselyov, O., Lisovsky, K.: Xml, xpath, xslt implementations as 130. Institute of Electrical and Electronics Engineers: IEEE Standards sxml, sxpath, and sxslt (2002). URL http://okmij.org/ftp/ Association (2014). URL http://standards.ieee.org/. papers/SXs.pdf. Accessed 2014-04-25 Accessed 2014-08-02 155. Klensin, J.: Simple Mail Transfer Protocol. RFC 5321 131. International Electrotechnical Commission: Website (2014). (Draft Standard) (2008). URL http://www.ietf.org/rfc/ URL http://www.iec.ch/. Accessed 2014-07-01 rfc5321.txt 36 Harald Lampesberger

156. Kohler, E., Handley, M., Floyd, S.: Datagram Congestion Con- 176. Melnikov, A., Zeilenga, K.: Simple Authentication and Security trol Protocol (DCCP). RFC 4340 (Proposed Standard) (2006). Layer (SASL). RFC 4422 (Proposed Standard) (2006). URL URL http://www.ietf.org/rfc/rfc4340.txt. Updated http://www.ietf.org/rfc/rfc4422.txt by RFCs 5595, 5596, 6335, 6773 177. microformats wiki: microformats 2 (2014). URL http:// 157. Kucherawy, M.: The Multipart/Report Media Type for the Re- microformats.org/wiki/microformats2. Accessed 2014- of Mail System Administrative Messages. RFC 6522 07-02 (INTERNET STANDARD) (2012). URL http://www.ietf. 178. Microsoft: Getting started with Nokia Notifications (2014). org/rfc/rfc6522.txt. Updated by RFC 6533 URL https://developer.nokia.com/asha/java/tools/ 158. Lampesberger, H.: A grammatical inference approach to nna. Accessed 2014-12-05 language-based anomaly detection in xml. In: 2013 International 179. Microsoft Azure: Azure Queues and Service Bus Queues - Com- Conference on Availability, Reliability and Security, ECTCM’13 pared and Contrasted (2014). URL http://msdn.microsoft. Workshop, pp. 685–693. IEEE (2013) com/library/azure/Hh767287.aspx. Accessed 2014-07-21 159. Lampesberger, H., Rady, M.: Monitoring of client-cloud interac- 180. Microsoft Azure: Windows Azure AMQP 1.0 Support in Service tion. In: B. Buchberger, A. Prinz, K.D. Schewe, B. Thalheim Bus (2014). URL http://www.windowsazure.com/en- (eds.) Correct Software in Web Applications and Web Services. us/documentation/articles/service-bus-amqp- Springer (2015). (to appear) overview/. Accessed 2014-02-21 160. Lampesberger, H., Winter, P., Zeilinger, M., Hermann, E.: An on- 181. Microsoft Developer Network: Sending files, attachments, line learning statistical model to detect malicious web requests. and soap messages via direct internet message encapsula- In: Security and Privacy in Communication Networks, Lecture tion (2002). URL http://msdn.microsoft.com/en-us/ Notes of the Institute for Computer Sciences, Social Informat- magazine/cc188797.aspx. Accessed 2014-07-15 ics and Telecommunications Engineering, vol. 96, pp. 19–38. 182. Microsoft Developer Network: COM+ (Component Ser- Springer Berlin Heidelberg (2012) vices) (2014). URL http://msdn.microsoft.com/en- 161. Langley, A., Chang, W.T.: QUIC Crypto (2013). URL us/library/windows/desktop/ms685978.aspx. Accessed https://docs.google.com/document/d/1g5nIXAIkN_Y- 2014-07-08 7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/. Accessed 2014-05- 183. Microsoft Developer Network: Message Queuing (MSMQ) 26 (2014). URL http://msdn.microsoft.com/en- 162. Larzon, L.A., Degermark, M., Pink, S., Jonsson, L.E., Fairhurst, us/library/ms711472.aspx. Accessed 2014-02-20 G.: The Lightweight User Datagram Protocol (UDP-Lite). RFC 184. Microsoft Developer Network: .NET Binary Format: XML Data 3828 (Proposed Standard) (2004). URL http://www.ietf. Structure (2014). URL http://msdn.microsoft.com/en- org/rfc/rfc3828.txt. Updated by RFC 6335 us/library/cc219210.aspx. Accessed 2014-07-09 163. Lengyel, E.: Open Data Description Language (OpenDDL). 185. Microsoft Developer Network: SQL Server Service Bro- URL http://openddl.org/ (2013). Accessed 2014-02-21 ker (2014). URL http://msdn.microsoft.com/en-us/ 164. Lentczner, M., Preston, D.: Reverse HTTP (2009). library/bb522893.aspx. Accessed 2014-02-23 URL https://datatracker.ietf.org/doc/draft- 186. Microsoft Developer Network: Windows Communication Foun- lentczner-rhttp/. Accessed 2014-03-04 dation (2014). URL http://msdn.microsoft.com/en-us/ 165. Levinson, E.: The MIME Multipart/Related Content-type. RFC library/dd456779.aspx. Accessed 2014-02-20 2387 (Proposed Standard) (1998). URL http://www.ietf. 187. Microsoft Developer Network: Windows Push No- org/rfc/rfc2387.txt tification Services (WNS) overview (2014). URL 166. Lindsay, J.: Web hooks to revolutionize the web (2007). URL http://msdn.microsoft.com/en-us/library/windows/ http://progrium.com/blog/2007/05/03/web-hooks- apps/hh913756.aspx. Accessed 2014-12-05 to-revolutionize-the-web/. Accessed 2014-02-20 188. Microsystems, S.: XDR: External Data Representation stan- 167. Lindsay, J.: From webhooks to the evented web (2012). dard. RFC 1014 (1987). URL http://www.ietf.org/rfc/ URL http://progrium.com/blog/2012/11/19/from- rfc1014.txt webhooks-to-the-evented-web/. Accessed 2014-072-02 168. Lindsay, J., Shakirzyanov, B.: NullMQ (2014). URL https: 189. Millard, P., Saint-Andre, P., Meijer, R.: XEP-0060: Publish- //github.com/progrium/nullmq. Accessed 2014-03-10 Subscribe (2010). URL http://xmpp.org/extensions/ 169. Lloret, J., Garcia, M., Tomas, J., Rodrigues, J.J.: Architecture and xep-0060.html. Accessed 2014-07-23 protocol for intercloud communication. Information Sciences 190. Miller, M., Saint-Andre, P.: XEP-0079: Advanced Message Pro- 258, 434–451 (2014) cessing (2005). URL http://xmpp.org/extensions/xep- 170. Magazinius, J.: Securing the mashed up web. Phd thesis, 0079.html. Accessed 2014-07-23 Chalmers University of Technology, Göteborg (2013) 191. Mitchell, S.: Ask a cloud networking expert: Why is multi- 171. Magazinius, J., Rios, B.K., Sabelfeld, A.: Polyglots: Crossing cast disabled in the cloud? how can you re-enable udp multi- origins by crossing formats. In: Proceedings of the 2013 ACM cast? (2014). URL http://blog.cohesiveft.com/2014/ SIGSAC Conference on Computer & Communications Security, 04/ask-cloud-networking-expert-why-is.html. Ac- CCS’13, pp. 753–764. ACM (2013) cessed 2014-12-07 172. Martens, W., Neven, F., Schwentick, T., Bex, G.J.: Expressive- 192. Mockapetris, P.: Domain names - concepts and facilities. RFC ness and complexity of xml schema. ACM Transactions on 1034 (INTERNET STANDARD) (1987). URL http://www. Database Systems 31(3), 770–813 (2006) ietf.org/rfc/rfc1034.txt. Updated by RFCs 1101, 1183, 173. Masinter, L.: Returning Values from Forms: multipart/form-data. 1348, 1876, 1982, 2065, 2181, 2308, 2535, 4033, 4034, 4035, RFC 2388 (Proposed Standard) (1998). URL http://www. 4343, 4035, 4592, 5936 ietf.org/rfc/rfc2388.txt 193. Mockapetris, P.: Domain names - implementation and specifica- 174. Masse, M.: WRML, the Web Resource Modeling Language tion. RFC 1035 (INTERNET STANDARD) (1987). URL http: (2014). URL https://github.com/wrml/wrml. Accessed //www.ietf.org/rfc/rfc1035.txt. Updated by RFCs 2014-07-15 1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2181, 175. Melnikov, A., Reschke, J.: Update to MIME regarding "charset" 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, Parameter Handling in Textual Media Types. RFC 6657 (Pro- 4343, 5936, 5966, 6604 posed Standard) (2012). URL http://www.ietf.org/rfc/ 194. Morley, M.: JSON-RPC 2.0 Specification (2013). URL http: rfc6657.txt //www.jsonrpc.org/specification. Accessed 2014-02-20 Technologies for Web and cloud service interaction: a survey 37

195. Mosquitto: An Open Source MQTT v3.1/v3.1.1 Broker (2014). 214. OASIS: WS-Trust 1.4 (2012). URL http://docs.oasis- URL http://mosquitto.org/. Accessed 2014-07-24 open.org/ws-sx/ws-trust/v1.4/errata01/os/ws- 196. Mozilla Development Networks: Same-origin policy trust-1.4-errata01--complete.html. Accessed (2014). URL https://developer.mozilla.org/en- 2014-07-17 US/docs/Web/Security/Same-origin_policy. Accessed 215. OASIS: Advanced Message Queuing Protocol (AMQP) 2014-07-01 WebSocket Binding (WSB) Version 1.0 (2014). URL 197. Murata, M., Laurent, S.S., Kohn, D.: XML Media Types. RFC http://docs.oasis-open.org/amqp-bindmap/amqp- 3023 (Proposed Standard) (2001). URL http://www.ietf. wsb/v1.0/amqp-wsb-v1.0.html. Accessed 2014-07-28 org/rfc/rfc3023.txt. Obsoleted by RFC 7303, updated by 216. OASIS: AMQP Working Group 0-10 (2014). URL RFC 6839 http://www.amqp.org/specification/0-10/amqp- 198. Natarajan, P., Amer, P.D., Stewart, R.: Multistreamed web trans- org-download. Accessed 2014-08-06 port for developing regions. In: Proceedings of the 2nd ACM 217. OASIS: MQTT Version 3.1.1 (2014). URL http: SIGCOMM Workshop on Networked Systems for Developing //docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt- Regions, NSDR’08, pp. 43–48. ACM (2008) v3.1.1.html. Accessed 2014-07-21 199. Netscape: An exploration of dynamic documents (1999). URL 218. Object Computing Inc.: Welcome to OpenDDS! (2013). URL https://web.archive.org/web/19990424021813/http: http://www.opendds.org. Accessed 2014-07-24 //fishcam.netscape.com/assist/net_sites/ 219. Object Computing Inc.: OpenDDS Developer’s Guide (2014). pushpull.html. Accessed 2014-07-27 URL http://download.ociweb.com/OpenDDS/OpenDDS- 200. Nottingham, M., Sayre, R.: The Atom Syndication Format. RFC latest.pdf. Accessed 2014-07-24 4287 (Proposed Standard) (2005). URL http://www.ietf. 220. Object Management Group: Documents Associated With Data org/rfc/rfc4287.txt. Updated by RFC 5988 Distribution Services, V1.2 (2007). URL http://www.omg. 201. OASIS: RELAX NG Specification (2001). URL https://www. org/spec/DDS/1.2/. Accessed 2014-02-20 oasis-open.org/committees/relax-ng/spec.html. Ac- 221. Object Management Group: Documents Associated With The cessed 2014-07-14 Real-Time Publish-Subscribe Wire Protocol DDS Interoperabil- 202. OASIS: UDDI Version 3.0.2 (2004). URL https: ity Wire Protocol Specification (DDSI), V2.1 (2009). URL //www.oasis-open.org/committees/uddi-spec/doc/ http://www.omg.org/spec/DDSI/2.1/. Accessed 2014-02- spec/v3/uddi-v3.0.2-20041019.htm. Accessed 2014-02- 20 21 222. Object Management Group: Documents Associated With 203. OASIS: OASIS Web Services Notification (WSN) TC (2006). CORBA, 3.3 (2012). URL http://www.omg.org/spec/ URL https://www.oasis-open.org/committees/tc_ CORBA/3.3/. Accessed 2014-02-20 home.php?wg_abbrev=wsn. Accessed 2014-07-14 223. Object Management Group: IIOP: OMG’s Internet Inter-ORB 204. OASIS: Web Services Security: SOAP Message Security 1.1 Protocol, A Brief Description (2012). URL http://www.omg. (WS-Security 2004) (2006). URL http://docs.oasis- org/library/iiop4.html. Accessed 2014-02-20 open.org/wss/v1.1/wss-v1.1-spec-errata-os- 224. Object Management Group: Documents Associated With BPMN SOAPMessageSecurity.htm. Accessed 2014-03-03 Version 2.0.2 (2014). URL http://www.omg.org/spec/ 205. OASIS: Web Services Business Process Execution Language BPMN/2.0.2/. Accessed 2014-04-25 Version 2.0 (2007). URL http://docs.oasis-open.org/ 225. Object Management Group: Documents Associated With DDS wsbpel/2.0/OS/wsbpel-v2.0-OS.html. Accessed 2014-04- Security (DDS-Security) 1.0 - Beta 1 (2014). URL http:// 25 206. OASIS: Web Services Atomic Transaction (WS- www.omg.org/spec/DDS-SECURITY/1.0/Beta1/. Accessed 2014-07-25 AtomicTransaction) Version 1.2 (2009). URL http://docs. oasis-open.org/ws-tx/wstx-wsat-1.2-spec.html. 226. Object Management Group: Website (2014). URL http:// Accessed 2014-04-23 www.omg.org/. Accessed 2014-07-01 207. OASIS: Web Services Business Activity (WS-BusinessActivity) 227. Obraczka, K.: Multicast transport protocols: a survey and taxon- Version 1.2 (2009). URL http://docs.oasis-open.org/ omy. IEEE Communications Magazine 36(1), 94–102 (1998) ws-tx/wstx-wsba-1.2-spec.html. Accessed 2014-07-17 228. O’Hara, J.: Toward a commodity enterprise middleware. Queue 208. OASIS: Web Services Coordination (WS-Coordination) Version 5(4), 48–55 (2007). URL http://queue.acm.org/detail. 1.2 (2009). URL http://docs.oasis-open.org/ws-tx/ cfm?id=1255424 wstx-wscoor-1.2-spec-os.pdf. Accessed 2014-04-23 229. Ong, L., Yoakum, J.: An Introduction to the Stream Control 209. OASIS: Web Services Reliable Messaging (WS- Transmission Protocol (SCTP). RFC 3286 (Informational) ReliableMessaging) Version 1.2 (2009). URL http: (2002). URL http://www.ietf.org/rfc/rfc3286.txt //docs.oasis-open.org/ws-rx/wsrm/v1.2/wsrm.html. 230. Open Cloud Computing Interface: GFD.185 – OCCI HTTP Accessed 2014-07-16 Rendering (v1.1) (2011). URL https://www.ogf.org/ 210. OASIS: WS-SecureConversation 1.4 (2009). URL http:// documents/GFD.185.pdf. Accessed 2015-01-28 docs.oasis-open.org/ws-sx/ws-secureconversation/ 231. OpenMAMA: Introduction to OpenMAMA (2014). URL v1.4/ws-secureconversation.html. Accessed 2014-07-16 http://www.openmama.org/what-is-openmama/ 211. OASIS: Advanced Message Queuing Protocol v1.0 (2011). introduction-to-openmama. Accessed 2014-07-09 URL http://docs.oasis-open.org/amqp/core/v1. 232. OpenSocial and Gadgets Specification Group: Opensocial speci- 0/os/amqp-core-overview-v1.0-os.html. Accessed fication 2.5.1 (2013). URL http://opensocial.github.io/ 2014-02-19 spec/2.5.1/OpenSocial-Specification.xml. Accessed 212. OASIS: Reference Architecture Foundation for Service Oriented 2014-07-08 Architecture Version 1.0 (2012). URL http://docs.oasis- 233. OpenStack: OCCI (2012). URL https://wiki.openstack. open.org/soa-rm/soa-ra/v1.0/soa-ra.html. Accessed org/wiki/Occi. Accessed 2015-01-28 2014-08-04 234. Opitz, P.: Clean urls for a better ranking (2006). 213. OASIS: WS-SecurityPolicy 1.3 (2012). URL http://docs. URL http://www.contentwithstyle.co.uk/content/ oasis-open.org/ws-sx/ws-securitypolicy/v1.3/ws- clean-urls-for-a-better-search-engine-ranking/. securitypolicy.html. Accessed 2014-07-17 Accessed 2014-05-28 38 Harald Lampesberger

235. Oracle: Oracle Tuxedo Message Queue Product Overview 253. Pautasso, C., Zimmermann, O., Leymann, F.: Restful web ser- (2013). URL http://docs.oracle.com/cd/E35855_01/ vices vs. "big"’ web services: Making the right architectural de- otmq/docs12c/overview/overview.html. Accessed 2014- cision. In: Proceedings of the 17th International Conference on 04-28 World Wide Web, WWW’08, pp. 805–814. ACM (2008) 236. Oracle: Java EE 7 Technologies (2014). URL http: 254. PeerCDN: FAQ (2014). URL https://peercdn.com/faq. //www.oracle.com/technetwork/java/javaee/tech/ html. Accessed 2014-07-27 index.html. Accessed 2014-07-08 255. Petcu, D., Martino, B., Venticinque, S., Rak, M., Máhr, T., Lopez, 237. Oracle: Java Message Service (2014). URL http://www. G., Brito, F., Cossu, R., Stopar, M., Šperka, S., Stankovski, V.: oracle.com/technetwork/java/jms/index.html. Ac- Experiences in building a mosaic of clouds. Journal of Cloud cessed 2014-02-19 Computing 2(1), 12 (2013) 238. Oracle: Java remote method invocation – distributed com- 256. Phelan, T.: Datagram Transport Layer Security (DTLS) over the puting for java (2014). URL http://www.oracle. Datagram Congestion Control Protocol (DCCP). RFC 5238 com/technetwork/java/javase/tech/index-jsp- (Proposed Standard) (2008). URL http://www.ietf.org/ 138781.html. Accessed 2014-02-19 rfc/rfc5238.txt 257. Pivotal Software, Inc.: AMQP URI Specification (2014). URL 239. Oracle: Java RMI over IIOP (2014). URL http://docs. http://www.rabbitmq.com/uri-spec.html. Accessed oracle.com/javase/7/docs/technotes/guides/rmi- 2014-07-27 iiop/index.html. Accessed 2014-07-09 258. Pivotal Software, Inc.: RabbitMQ (2014). URL https://www. 240. Oracle: WebLogic Server (2014). URL http://www. .com/. Accessed 2014-02-19 oracle.com/us/products/middleware/cloud-app- 259. Postel, J.: User Datagram Protocol. RFC 768 (INTERNET foundation/weblogic/overview/index.html. Accessed STANDARD) (1980). URL http://www.ietf.org/rfc/ 2014-03-28 rfc768.txt 241. Organization for the Advancement of Structured Information 260. Postel, J.: Internet Protocol. RFC 791 (INTERNET STAN- Standards: Website (2014). URL http://www.omg.org/. Ac- DARD) (1981). URL http://www.ietf.org/rfc/rfc791. cessed 2014-07-01 txt. Updated by RFCs 1349, 2474, 6864 242. Osborne, J., Diquet, A.: When security gets in the way 261. Postel, J.: Transmission Control Protocol. RFC 793 (INTER- – pentesting mobile apps that use certificate pinning NET STANDARD) (1981). URL http://www.ietf.org/ (2012). URL https://media.blackhat.com/bh-us- rfc/rfc793.txt. Updated by RFCs 1122, 3168, 6093, 6528 12/Turbo/Diquet/BH_US_12_Diqut_Osborne_Mobile_ 262. Postel, J., Reynolds, J.: File Transfer Protocol. RFC 959 (IN- Certificate_Pinning_Slides.pdf. BlackHat USA, TERNET STANDARD) (1985). URL http://www.ietf. Accessed 2014-07-29 org/rfc/rfc959.txt. Updated by RFCs 2228, 2640, 2773, 243. OW2 Consortium: JORAM: Java Open Reliable Asyn- 3659, 5797, 7151 chronous Messaging (2014). URL http://joram.ow2.org/ 263. Postel, J., White, J.: Procedure call documents: Version 2. RFC technical.html. Accessed 2014-07-23 674 (1974). URL http://www.ietf.org/rfc/rfc674.txt 244. OWASP: Certificate and Public Key Pinning (2014). URL 264. Potti, P.K.: On the design of web services: Soap vs. rest. UNF https://www.owasp.org/index.php/Certificate_and_ Theses and Dissertations, Paper 138 (2011). URL http:// Public_Key_Pinning. Accessed 2014-07-29 digitalcommons.unf.edu/etd/138/ 245. Paoli, J.: Speed and mobility: An approach for http 2.0 265. PrismTech: OpenSplice DDS Community (2014). URL to make mobile apps and the web faster (2012). URL http://www.prismtech.com/opensplice/opensplice- http://blogs.msdn.com/b/interoperability/ dds-community. Accessed 2014-07-24 archive/2012/03/25/speed-and-mobility-an- 266. pupsubhubbub: A simple, open, webhook based pubsub protocol approach-for-http-2-0-to-make-mobile-apps-and- & open source reference implementation (2014). URL https: the-web-faster.aspx. Accessed 2014-06-04 //code.google.com/p/pubsubhubbub/. Accessed 2014-07- 246. Paterson, I., Saint-Andre, P., Stout, L., Tilanus, W.: XEP- 02 0206: XMPP Over BOSH (2014). URL http://xmpp.org/ 267. Rackspace: Cloud Queues (2014). URL http: extensions/xep-0206.html. Accessed 2014-07-23 //docs.rackspace.com/queues/api/v1.0/cq- 247. Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J.: XEP-0124: gettingstarted/content/DB_Overview.html. Accessed Bidirectional-streams Over Synchronous HTTP (BOSH) (2010). 2014-07-21 268. Rady, M.: Formal definition of service availability in cloud com- URL http://xmpp.org/extensions/xep-0124.html. Ac- puting using owl. In: Computer Aided Systems Theory - EURO- cessed 2014-03-04 CAST 2013, Lecture Notes in Computer Science, vol. 8111, pp. 248. Pautasso, C.: Composing restful services with jopera. In: Soft- 189–194. Springer Berlin Heidelberg (2013) ware Composition, Lecture Notes in Computer Science, vol. 269. Rady, M.: Generating an excerpt of a service level agreement 5634, pp. 142–159. Springer Berlin Heidelberg (2009) from a formal definition of non-functional aspects using owl 249. Pautasso, C.: RESTful Web service composition with BPEL for (2014). Conceptual Modelling with Specific focus on Service- REST. Data & Knowledge Engineering 68(9), 851–866 (2009) Oriented Systems, Special Issue of the Journal of Universal Com- 250. Pautasso, C.: Bpmn for rest. In: Business Process Model and puter Science (to appear) Notation, Lecture Notes in Business Information Processing, 270. Ramsdell, B., Turner, S.: Secure/Multipurpose Internet Mail Ex- vol. 95, pp. 74–87. Springer Berlin Heidelberg (2011) tensions (S/MIME) Version 3.2 Message Specification. RFC 251. Pautasso, C., Wilde, E.: Why is the web loosely coupled?: A 5751 (Proposed Standard) (2010). URL http://www.ietf. multi-faceted metric for service design. In: Proceedings of the org/rfc/rfc5751.txt 18th International Conference on World Wide Web, WWW’09, 271. Red Hat Enterprise: MRG – Messaging, Realtime, Grid (2009). pp. 911–920. ACM (2009) URL http://www.redhat.com/f/pdf/MRG_brochure_ 252. Pautasso, C., Wilde, E.: Restful web services: Principles, pat- web.pdf. Accessed 2014-07-21 terns, emerging technologies. In: Proceedings of the 19th Inter- 272. Rescorla, E.: HTTP Over TLS. RFC 2818 (Informational) national Conference on World Wide Web, WWW’10, pp. 1359– (2000). URL http://www.ietf.org/rfc/rfc2818.txt. 1360. ACM (2010) Updated by RFCs 5785, 7230 Technologies for Web and cloud service interaction: a survey 39

273. Rescorla, E.: SSL and TLS: designing and building secure sys- 295. Shelby, .: Constrained RESTful Environments (CoRE) Link tems. Addison-Wesley (2001) Format. RFC 6690 (Proposed Standard) (2012). URL http: 274. Rescorla, E., Modadugu, N.: Datagram Transport Layer Security //www.ietf.org/rfc/rfc6690.txt Version 1.2. RFC 6347 (Proposed Standard) (2012). URL http: 296. Shelby, Z., Hartke, K., Bormann, C.: The Constrained Applica- //www.ietf.org/rfc/rfc6347.txt tion Protocol (CoAP). RFC 7252 (Proposed Standard) (2014). 275. Restlet: The Leading Web API Platform for Java (2014). URL URL http://www.ietf.org/rfc/rfc7252.txt http://restlet.org/. Accessed 2014-05-05 297. Sit, E.N.: Reverse http tunneling for firewall traversal (2000). 276. Ristic, D.: WebRTC data channels (2014). URL http://www. Dept. of Electrical Engineering and Computer Science, Mas- html5rocks.com/en/tutorials/webrtc/datachannels/. sachusetts Institute of Technology. Accessed 2014-06-05 298. Software AG: Terracotta Universal Messaging (2014). URL 277. Roskind, J.: QUIC: Multiplexed stream transport over udp https://www.softwareag.com/corporate/images/ (2013). URL https://docs.google.com/document/d/ SAG_Terracotta_Universal_Messaging_FS_Jun14_Web_ 1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34. Ac- tcm16-114090.pdf. Accessed 2014-06-04 cessed 2014-04-30 299. Souders, S.: Sharding dominant domains (2009). URL http: 278. RSS Advisory Board: RSS 2.0 Specification (2009). URL //www.stevesouders.com/blog/2009/05/12/sharding- http://www.rssboard.org/rss-specification. Ac- dominant-domains/. Accessed 2014-06-04 cessed 2014-02-21 300. Soylu, A., Mödritscher, F., Wild, F., Causmaecker, P.D., Desmet, 279. RTI: Connext DDS Software (2014). URL http://www.rti. P.: Mashups by orchestration and widget-based personal environ- com/products/index.html. Accessed 2014-07-24 ments: Key challenges, solution strategies, and an application. 280. Russell, A.: Comet: Low latency data for the browser Program: electronic library and information systems 46(4), 383– (2006). URL http://infrequently.org/2006/03/comet- 428 (2012) low-latency-data-for-the-browser/. Accessed 2014- 301. Stampy: Java implementation of the STOMP 1.2 specification 02-20 (2013). URL http://mrstampy.github.io/Stampy/. Ac- 281. Russell, A., Wilkins, G., Davis, D., Nesbitt, M.: Bayeux Proto- cessed 2014-07-24 col – Bayeux 1.0.0 (2007). URL http://svn.cometd.org/ 302. Stevens, W.R.: TCP/IP Illustrated (Vol. 1): The Protocols. trunk/bayeux/bayeux.html. Accessed 2014-03-04 Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 282. Ryck, P., Decat, M., Desmet, L., Piessens, F., Joosen, W.: Secu- USA (1993) rity of web mashups: A survey. In: Information Security Tech- 303. Stewart, R.: Stream Control Transmission Protocol. RFC 4960 nology for Applications, Lecture Notes in Computer Science, vol. (Proposed Standard) (2007). URL http://www.ietf.org/ 7127, pp. 223–238. Springer Berlin Heidelberg (2012) rfc/rfc4960.txt. Updated by RFCs 6096, 6335, 7053 283. Saint-Andre, P.: Extensible Messaging and Presence Protocol 304. Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Conrad, P.: (XMPP): Address Format. RFC 6122 (Proposed Standard) Stream Control Transmission Protocol (SCTP) Partial Reliabil- (2011). URL http://www.ietf.org/rfc/rfc6122.txt ity Extension. RFC 3758 (Proposed Standard) (2004). URL 284. Saint-Andre, P.: Extensible Messaging and Presence Protocol http://www.ietf.org/rfc/rfc3758.txt (XMPP): Core. RFC 6120 (Proposed Standard) (2011). URL 305. STOMP: The Simple Text Oriented Messaging Protocol http://www.ietf.org/rfc/rfc6120.txt v1.2 (2012). URL http://stomp.github.io/stomp- 285. Saint-Andre, P.: Extensible Messaging and Presence Protocol specification-1.2.html. Accessed 2014-02-19 (XMPP): Instant Messaging and Presence. RFC 6121 (Pro- 306. Limited: Message queues as a service in the cloud posed Standard) (2011). URL http://www.ietf.org/rfc/ (2013). URL http://stormmq.com/. Accessed 2014-02-21 rfc6121.txt 307. Stout, L., Moffitt, J., Cestari, E.: An XMPP Sub-protocol for 286. Saint-Andre, P., Šimerda, P.: XEP-0231: Bits of Binary (2008). WebSocket (2014). URL https://datatracker.ietf.org/ URL http://xmpp.org/extensions/xep-0231.html. Ac- doc/draft-ietf-xmpp-websocket/. Accessed 2014-06-16 cessed 2014-07-25 308. SwiftMQ: Enterprise messaging platform (2014). URL hhttp: 287. Saint-Andre, P., Smith, K.: XEP-0163: Personal Eventing Pro- //www.swiftmq.com/. Accessed 2014-07-23 tocol (2010). URL http://xmpp.org/extensions/xep- 309. The Blog: New chromium security features, june 0163.html. Accessed 2014-07-23 2011 (2011). URL http://blog.chromium.org/2011/06/ 288. Sassaman, L., Patterson, M., Bratus, S., Locasto, M.: Security new-chromium-security-features-june.html. Accessed applications of formal language theory. IEEE Systems Journal 2014-07-29 7(3), 489–500 (2013) 310. The Chromium Projects: SPDY: An experimental protocol for 289. SAX Project: Simple for xml (sax) (2004). URL http:// a faster web. URL http://dev.chromium.org/spdy/spdy- www.saxproject.org/. Accessed 2014-06-05 whitepaper. Accessed 2014-03-05 290. Schantz, R.: Commentary on procedure calling as a network pro- 311. The Open Group: CAE Specification, DCE 1.1: Remote Pro- tocol. RFC 684 (1975). URL http://www.ietf.org/rfc/ cedure Call (1997). URL http://pubs.opengroup.org/ rfc684.txt onlinepubs/9629399/. Accessed 2014-07-09 291. Scharf, M., Ford, A.: Multipath TCP (MPTCP) Application In- 312. Thurlow, R.: RPC: Remote Procedure Call Protocol Specification terface Considerations. RFC 6897 (Informational) (2013). URL Version 2. RFC 5531 (Draft Standard) (2009). URL http:// http://www.ietf.org/rfc/rfc6897.txt www.ietf.org/rfc/rfc5531.txt 292. Schewe, K.D., Bósa, K., Lampesberger, H., Ma, J., Rady, M., 313. TIBCO: Enterprise Message Service (2014). URL Vleju, M.B.: Challenges in cloud computing. Scalable Comput- http://www.tibco.com/products/automation/ ing: Practice and Experience 12(4), 385–390 (2011) enterprise-messaging/enterprise-message- 293. Scripting News, Inc: XML-RPC.com (1999). URL http:// service/default.jsp. Accessed 2014-07-21 xmlrpc.scripting.com/default.html. Accessed 2014-02- 314. TIBCO: Rendezvous Messaging Middleware (2014). 20 URL http://www.tibco.com/products/automation/ 294. Shafranovich, Y.: Common Format and MIME Type for Comma- enterprise-messaging/rendezvous/default.jsp. Separated Values (CSV) . RFC 4180 (Informational) (2005). Accessed 2014-07-22 URL http://www.ietf.org/rfc/rfc4180.txt. Updated 315. TIBCO: Web Messaging for Enterprise Message Service (2014). by RFC 7111 URL http://www.tibco.com/products/automation/ 40 Harald Lampesberger

enterprise-messaging/web-messaging/default.jsp. 340. W3C: XML Schema Part 0: Primer Second Edition (2004). URL Accessed 2014-07-22 http://www.w3.org/TR/xmlschema-0/. Accessed 2014-07- 316. Toosi, A.N., Calheiros, R.N., Buyya, R.: Interconnected cloud 14 computing environments: Challenges, taxonomy, and survey. 341. W3C: Describing Media Content of Binary Data in XML ACM Comput. Surv. 47(1), 7:1–7:47 (2014) (2005). URL http://www.w3.org/TR/xml-media-types/. 317. Tuexen, M., Seggelmann, R., Rescorla, E.: Datagram Transport Accessed 2014-07-15 Layer Security (DTLS) for Stream Control Transmission Pro- 342. W3C: SOAP Message Transmission Optimization Mechanism tocol (SCTP). RFC 6083 (Proposed Standard) (2011). URL (2005). URL http://www.w3.org/TR/soap12-mtom/. Ac- http://www.ietf.org/rfc/rfc6083.txt cessed 2014-02-20 318. Twin Oaks Computing, Inc.: What can DDS do for You? (2013). 343. W3C: Web Services Choreography Description Language Ver- URL http://www.omg.org/hot-topics/documents/dds/ sion 1.0) (2005). URL http://www.w3.org/TR/ws-cdl- CoreDX_DDS_Why_Use_DDS.pdf. Accessed 2014-07-24 10/. Accessed 2014-04-25 319. Twin Oaks Computing, Inc.: CoreDX DDS Data Distri- 344. W3C: SOAP Version 1.2 Part 1: Messaging Framework (Sec- bution Service Middleware (2014). URL http://www. ond Edition) (2007). URL http://www.w3.org/TR/soap12- twinoakscomputing.com/coredx. Accessed 2014-07-24 part1/. Accessed 2014-02-20 320. Twitter, Inc.: finagle (2014). URL http://twitter.github. 345. W3C: Web Services Policy 1.5 - Primer (2007). URL http: io/finagle/guide/. Accessed 2014-07-15 //www.w3.org/TR/ws-policy-primer/. Accessed 2014-07- 321. UCLouvain ip networking lab: MultiPath TCP - Linux Kernel 17 implementation (2014). URL http://multipath-tcp.org/ 346. W3C: Extensible Markup Language (XML) 1.0 (Fifth Edi- pmwiki.php/Users/Android. Accessed 2014-08-06 tion) (2008). URL http://www.w3.org/TR/2008/REC-xml- 322. Unicode, Inc.: What is unicode? (2013). URL http://www. 20081126/. Accessed 2014-02-17 unicode.org/standard/WhatIsUnicode.html. Accessed 2014-06-16 347. W3C: XML-binary Optimized Packaging (2008). URL http: 323. Veen, R.: The OGDL Specification (2014). URL http://ogdl. //www.w3.org/TR/xop10/. Accessed 2014-02-20 org/spec/. Accessed 2014-02-21 348. W3C: Web Application Description Language (2009). URL 324. Vinoski, S.: Advanced message queuing protocol. IEEE Internet http://www.w3.org/Submission/wadl/. Accessed 2014- Computing 10(6), 87–89 (2006) 03-28 325. Vleju, M.B.: A client-centric asm-based approach to identity 349. W3C: Cascading Style Sheets (CSS) Snapshot 2010 (2011). management in cloud computing. In: Advances in Conceptual URL http://www.w3.org/TR/CSP/. Accessed 2014-07-02 Modeling, Lecture Notes in Computer Science, vol. 7518, pp. 350. W3C: Scalable Vector Graphics (SVG) 1.1 (Second Edition) 34–43. Springer Berlin Heidelberg (2012) (2011). URL http://www.w3.org/TR/SVG11/. Accessed 326. Vleju, M.B.: Automatic authentication to cloud-based services 2014-02-20 (2014). Conceptual Modelling with Specific focus on Service- 351. W3C: Web Services Eventing (WS-Eventing) (2011). URL Oriented Systems, Special Issue of the Journal of Universal Com- http://www.w3.org/TR/ws-eventing/. Accessed 2014-07- puter Science (to appear) 14 327. Vogels, W.: Web services are not distributed objects. IEEE Inter- 352. W3C: Content Security Policy 1.0 (2012). URL http://www. net Computing 7(6), 59–66 (2003) w3.org/TR/rdfa-core/. Accessed 2014-07-02 328. W3C: HTTP-NG Binary Wire Protocol (1998). URL http:// 353. W3C: OWL 2 Web Ontology Language Document Overview www.w3.org/TR/WD-HTTP-NG-wire/. Accessed 2014-06-04 (Second Edition) (2012). URL http://www.w3.org/TR/ 329. W3C: SMUX Protocol Specification (1998). URL http:// owl2-overview/. Accessed 2014-07-02 www.w3.org/TR/WD-mux. Accessed 2014-06-04 354. W3C: Server-Sent Events (2012). URL http://www.w3.org/ 330. W3C: HTML 4.01 Specification (1999). URL http://www.w3. TR/eventsource/. Accessed 2014-06-03 org/TR/html4/. Accessed 2014-02-20 355. W3C: The WebSocket API (2012). URL http://www.w3.org/ 331. W3C: SOAP Messages with Attachments (2000). URL http: TR/websockets/. Accessed 2014-02-21 //www.w3.org/TR/SOAP-attachments. Accessed 2014-07- 356. W3C: HTML Microdata (2013). URL http://www.w3.org/ 15 TR/microdata/. Accessed 2014-07-02 332. W3C: Web Services Description Language (WSDL) 1.1 (2001). 357. W3C: RDFa Core 1.1 - Second Edition (2013). URL http: URL http://www.w3.org/TR/wsdl. Accessed 2014-02-21 //www.w3.org/TR/rdfa-core/. Accessed 2014-07-02 333. W3C: XHTML 1.0 The Extensible HyperText Markup Lan- 358. W3C: Semantic Web (2013). URL http://www.w3.org/ guage (Second Edition) (2002). URL http://www.w3.org/ standards/semanticweb/. Accessed 2014-06-30 TR/xhtml1/. Accessed 2014-02-20 359. W3C: WebRTC 1.0: Real-time Communication Between 334. W3C: Mathematical Markup Language (MathML) Version 2.0 Browsers (2013). URL http://www.w3.org/TR/webrtc/. (Second Edition) (2003). URL http://www.w3.org/TR/ Accessed 2014-02-21 MathML2/. Accessed 2014-02-20 335. W3C: Document Object Model (DOM) Level 3 Core Specifica- 360. W3C: A Little History of the World Wide Web (2014). URL tion (2004). URL http://www.w3.org/TR/DOM-Level-3- http://www.w3.org/History.html. Accessed 2014-12-05 Core/. Accessed 2014-02-17 361. W3C: Cross-Origin Resource Sharing (2014). URL http:// 336. W3C: RDF/XML Syntax Specification (Revised) (2004). URL www.w3.org/TR/cors/. Accessed 2014-07-01 http://www.w3.org/TR/rdf-syntax-grammar/. Accessed 362. W3C: Efficient XML Interchange (EXI) Format 1.0 (Second Edi- 2014-02-20 tion) (2014). URL http://www.w3.org/TR/exi/. Accessed 337. W3C: SOAP 1.2 Attachment Feature (2004). URL http:// 2014-06-18 www.w3.org/TR/soap12-af/. Accessed 2014-07-15 363. W3C: HTML5 (2014). URL http://www.w3.org/TR/ 338. W3C: Web Services Addressing (WS-Addressing) (2004). URL /. Accessed 2014-02-17 http://www.w3.org/Submission/ws-addressing/. Ac- 364. W3C: JSON-LD 1.0 (2014). URL http://www.w3.org/TR/ cessed 2014-03-03 json-ld/. Accessed 2014-07-02 339. W3C: XML Information Set (Second Edition) (2004). URL 365. Waher, P.: XEP-0337: Event Logging over XMPP (2014). URL http://www.w3.org/TR/xml-infoset/. Accessed 2014-08- http://xmpp.org/extensions/xep-0337.html. Accessed 02 2014-07-23 Technologies for Web and cloud service interaction: a survey 41

366. Web Services Interoperability Organization: Attachments Profile Version 1.0 (2006). URL http://www.ws-i.org/Profiles/ AttachmentsProfile-1.0.html. Accessed 2014-07-14 367. Web Services Interoperability Organization: Basic Profile Version 1.2 (2010). URL http://ws-i.org/Profiles/ BasicProfile-1.2-2010-11-09.html. Accessed 2014-05- 05 368. Web Services Interoperability Organization: Basic Profile Version 2.0 (2010). URL http://ws-i.org/Profiles/ BasicProfile-2.0-2010-11-09.html. Accessed 2014-05- 05 369. White, J.: High-level framework for network-based resource sharing. RFC 707 (1975). URL http://www.ietf.org/rfc/ rfc707.txt 370. Wikidot.com: RestMS (2008). URL http://www.restms. org/. Accessed 2014-02-21 371. Wildgrube, M.: Structured Data Exchange Format (SDXF). RFC 3072 (Informational) (2001). URL http://www.ietf.org/ rfc/rfc3072.txt 372. Workflow Patterns Initiative: Documentation (2011). URL http://www.workflowpatterns.com/documentation/. Accessed 2014-04-25 373. World Wide Web Consortium: Website (2014). URL http:// www.w3.org/. Accessed 2014-07-01 374. WSO2: WSO2 Message Broker (2014). URL http://wso2. com/products/message-broker/. Accessed 2014-07-23 375. XML-RPC Description Language: Getting started with xrdl (2010). URL https://code.google.com/p/xrdl/wiki/ GettingStarted. Accessed 2014-07-09 376. XMPP: IoT Systems (2013). URL http://wiki.xmpp.org/ web/Tech_pages/IoT_systems. Accessed 2014-07-24 377. Yergeau, F.: UTF-8, a transformation format of ISO 10646. RFC 3629 (INTERNET STANDARD) (2003). URL http://www. ietf.org/rfc/rfc3629.txt 378. Zaha, J., Dumas, M., ter Hofstede, A., Barros, A., Decker, G.: Service interaction modeling: Bridging global and local views. In: 10th IEEE International Enterprise Distributed Object Com- puting Conference, EDOC’06, pp. 45–55 (2006) 379. Zarras, A.: A comparison framework for middleware infrastruc- tures. Journal of Object Technology 3(5), 103–123 (2004) 380. ZeroC, Inc.: The Internet Communications Engine (ICE) (2013). URL http://www.zeroc.com/ice.html. Accessed 2014-02- 21 381. Zhang, L.: Building facebook messenger (2011). URL https: //www.facebook.com/notes/facebook-engineering/ building-facebook-messenger/10150259350998920. Accessed 2014-06-13 382. Zhao, W., Melliar-Smith, P., Moser, L.: Fault tolerance middle- ware for cloud computing. In: IEEE 3rd International Conference on Cloud Computing, CLOUD’10, pp. 67–74. IEEE (2010) 383. Zimmermann, H.: Osi reference model–the iso model of archi- tecture for open systems interconnection. IEEE Transactions on Communications 28(4), 425–432 (1980)