Towards a Solution for the Public Web-Based GIS Monitoring and Alerting System - Geoinformatics for Intelligent Transportation - page 122

Table 1 Comparison of web services architectural styles
Attribute WEDA-style REST-style RPC-style

Architecture SOA 2.0 SOA SOA

Distributed
system type

Hybrid (message
passing and call/
return)

Call/return Call/return

Addressability Multiple endpoints

per service (clients,
server)

Unique URI address per
resource

One endpoint per
service

Common
transport

HTML5 WebSockets HTTP HTTP

State Statefull Stateless Stateless

Flow control Asynchronous Synchronous Synchronous (over

FW-friendly
transport)

Process com.
models

One-to-one, one-to-
many, many-to-many

One-to-one One-to-one

Latency Best (after improving

admission and flow
control)

Good Good

Throughput Extremely high Bad Bad

Instance
context

Per session Per call Per call

Scalability Best in terms of con-

current clients

Good Good

Coupling Loose (only event

type de nitions in
duplex contracts)

Functionally tightly cou-
pled (MIME types in self-
descriptive resource
representations)

Functionally tightly
coupled (operations
and data types in
contract)

Data interface Inherited (no

restriction)

Generic (e.g. HTTP
verbs, MIME)

Service description
(e.g. WSDL)

Common data
format

Inherited (no
restriction)

HTTP resource represen-
tation, XML, JSON

SOAP

Deployment
topologies

Enterprise service
bus

Hub and spoke
(centralized)

Hub and spoke
(centralized)

Coordination Esb ' s native func-

tions for orchestra-
tion and
choreography, no
scheduler

Resource-oriented work-
flows (theoretical-atom,
rss, dynamic hyperlinks in
practice)

Service-oriented
workflows, sched-
uler required

Coordination Esb ' s native func-

tions for orchestra-
tion and
choreography, no
scheduler

Resource-oriented work-
flows (theoretical-atom,
rss, dynamic hyperlinks in
practice)

Service-oriented
workflows, sched-
uler required