SWE30003 Software Architectures and S1 2024

Design

SWE30003
Software Architectures and Design
Lecture 10
Service Oriented Architectures (SOA) and
Web Services

Logistical matters
 Weekly submissions – A & Q
 Week 2: 361 & 346 out of 434;
 Week 3: 380 & 366 out of 434;
 Week 4: 395 & 393 out of 434;
 Week 5: 398 & 389 out of 432;
 Week 6: 379 & 375 out of 430;
 Week 7: 326 & 320 out of 430;
 Week 8: 359 & 348 out of 430,
 Week 9:
 Week 10:
No late submission, hurdle requirement

 Assignment 3: … Questions? 2

© Swinburne University of Technology 1

SWE30003 Software Architectures and S1 2024
Design

Question to Answer – Week 9

Discuss the differences, advantages, and disadvantages

of data-centred and data-flow architectures. Give
examples where either of these two styles would be
applicable.

Required Readings - Week 10

Service Oriented Architectures (SOAP, REST, and Micro-Services)
 Michael N. Huhns, Munindar P. Singh: Service-Oriented
Computing: Key Concepts and Principles. IEEE
Internet Comput.9(1): 75-81 (2005) (Link to an external site)
 Stefan Tilkov: A Brief Introduction to REST. InfoQ (2007) (Link to
an external site)
 Chris Richardson: Microservices: Decomposing Applications for
Deployability and Scalability. InfoQ (2014) (Link to an external
site)
 P Jamshidi, C Pahl, NC Mendonça, J Lewis, S Tilkov:
Microservices: The journey so far and challenges ahead. IEEE
Software (2018) (Link to an external site)
4

© Swinburne University of Technology 2

SWE30003 Software Architectures and S1 2024
Design

Additional Resources/Readings
 Follow the links provided …
 Michael Papazoglou: Web Services: Principles and
Technology, Pearson/Prentice Hall, 2008. Chapters 1 & 2
(and more)
 Leonard Richardson and Sam Ruby: RESTful Web
Services, O’Reilly, 2007. Chapter 1 (and more)
 Webber, Parastatidis, Robinson: REST in Practice, O’Reilly,
2010 (Free download http://it-ebooks.info/book/393/)
 InfoQ (http://www.infoq.com): SOA, Web services, REST,
Microservices, Enterprise Architecture, …
5

Content

 Software services & web services

 Some concepts you need to understand
 Service oriented architecture (SOA)
 Web application architectural styles and middleware
 WS* (SOAP) approach
 REST approach
 Microservices

© Swinburne University of Technology 3

SWE30003 Software Architectures and S1 2024
Design

The Web

 Initially, documents – for sharing between humans:

documents on the web
 Web Server: hosting documents
 Web Client (Brower): reading/using documents

 Distributed
 Searchable/addressable
 Extensible/unbounded
 …
7

Enterprise (Software) Systems

 Distributed
 Integration (vs greenfield decomposition)
 Business process
 Cross-organisation, cross-geography
 Large-scale
 Addressable
 Then, software – for sharing between machines (&
between humans): software on the web
 How? … make software a “service” deployable on the web
8

© Swinburne University of Technology 4

SWE30003 Software Architectures and S1 2024
Design

Service / Software Service / Web Service

A (software) service – beyond component:
 Independently deployable,
 Self-contained,
 Self-describing,
 Discoverable (open),
 Composable,
 Software system (component).
Not necessarily on the Web …
web service = service + web: a service deployed on
9
the web using web technology.
9

Web Services in the Enterprise

Web Services: W3C Definition

 A Web service is a software system identified by a URL,
whose public interfaces and bindings are defined and
described using XML.
 Its definition can be discovered by other software
systems ?? Maybe if WADL is used
 These systems may then interact with the Web service
using XML based messages conveyed by Internet
protocols (not necessarily Web protocols!)

W3C definition does not apply to

RESTful ‘Web services’!
10

10

© Swinburne University of Technology 5

SWE30003 Software Architectures and S1 2024
Design

Web Services in the Enterprise – Example (business/sales process management)

Need to make an existing business process more flexible

Example from IBM Rational 11

11

12

12

© Swinburne University of Technology 6

SWE30003 Software Architectures and S1 2024
Design

Web Services in the Enterprise

Advantages of Web Services for Business

 Within an enterprise (Enterprise Application Integration)
 Accelerate and reduce the cost of integration
 Save on infrastructure deployment & management costs
 Reduce skill requirements
 Improve reuse
 Improve flexibility leads quicker response to market opportunities
 Between enterprises (e-Business integration)
 Providing service to a company’s customers
 e.g., an Insurance company wishes to link its systems to the systems of a
new institutional customer (IAG for RACV, NRMA etc)
 Accessing services from a company’s partners and suppliers
 e.g., dynamically link to new partners and suppliers to offer their services
to complement the value the company provides (Master Card from Coles)
 Standards and common infrastructure reduce the barriers
 Simplicity and reuse accelerates deployment
13
 Dynamics opens new business opportunities

13

Content

 Software services / web services

 Some concepts you need to understand
 Service oriented architecture (SOA)
 Web application architectural styles and middleware
 WS* (SOAP) approach
 REST approach
 Microservices

14

14

© Swinburne University of Technology 7

SWE30003 Software Architectures and S1 2024
Design

Some underlying concepts …

 Functional and non-functional properties
 Stateless and stateful services
 Granularity
 Synchronicity
 Separation of interfaces and implementation
 Loose coupling

15

15

Some concepts …

Service Properties & State

 Functional & non-functional properties:
 The functional service description details the operational characteristics that
define the overall behavior of the service,
 The non-functional description targets service quality attributes, e.g., service
metering and cost, performance metrics (response time or accuracy),
security, authorization, authentication, scalability, & availability, etc.
 Stateless or stateful services:
 Services that can be invoked repeatedly without having to maintain context
or state are called stateless.
 Simple informational services are stateless.

 Services that require their context to be preserved from one invocation to

the next are called stateful.
 Complex services (business processes) typically involve stateful interactions.
16

16

© Swinburne University of Technology 8

SWE30003 Software Architectures and S1 2024
Design

Some concepts …

Granularity
 Service granularity:
 Simple services are discrete in nature, exhibit normally a
request/reply mode of operation & are of fine granularity, i.e.,
they are atomic in nature.
 Complex services are coarse-grained, e.g., a PurchaseOrder.
These involve interactions with other services and possibly end-
users in a single or multiple sessions.
 Coarse-grained communication implies larger and richer data
structures, (viz. those supported by XML).

17

17

Some concepts …

Synchronous & asynchronous communication

sending receiving
 Synchronous communication which is application application
synchronized between two communicating
application systems, which must both up and
running.
 Execution flow at the client’s side is interrupted to
execute the call. block request
unblock processing
 Asynchronous communication where
the caller employs a send and forget approach
that allows it to continue to execute after it sends
the message.
 Here an application sends a request to another
while it continues its own processing activities.

18

18

© Swinburne University of Technology 9

SWE30003 Software Architectures and S1 2024
Design

Some concepts …

Service Interface (API) & Implementation

 The service interface defines service functionality visible to the
external world and provides the means to access this functionality.
 The service describes its own interface characteristics, i.e., the
operations available, the parameters, data-typing and the access
protocols, in a way that other software modules can determine
what it does, how to invoke its functionality, & what result to
expect in return.
 The service implementation realizes a specific service interface whose
implementation details are hidden from its users.
 Different service providers using any programming language of
their choice may implement the same interface.

19

19

Perspectives on Web Services

Client Perspective Provider Perspective

What How to
does it represent it? How to
do? build it?
Interface
How do I Implementation
use it?

Where Where to
can I find How to host it?
it? publish it?

20

20

© Swinburne University of Technology 10

SWE30003 Software Architectures and S1 2024
Design

Some concepts …

Loose Coupling
Coupling indicates the degree of dependency any two systems have on
each other. Some types relevant to enterprise computing include:
Type of Coupling Problem Description Reduced by

Functional One module relies on the Well defined interface/API describing inputs and
internal workings of others outputs
Interface Interfaces reflect the Avoid detailed mandatory parameters;
implementation details Use more general methods and message
passing (do not get too fine-grained)
Data Structure Data passed between Explicitly define formats, e.g XML in interface;
modules reflects internal Allow multiple representations e.g.mime-types;
representations, ‘Vertical’ standards that define semantics of
or is over-constrained messages
Temporal Client blocked while Asynchronous messages; Explicitly define
waiting response behaviour in interface e.g. abstract BPEL;
Process over-constrained Interaction via events / event-driven processes
Address/URI Addresses change Do not hard code references;
Providers change Virtualise services; 21
URI patterns change Use middleware directory services

21

Content

 Software services / web services

 Some concepts you need to understand
 Service oriented architecture (SOA)
 Web Application architectural styles and middleware
 WS* (SOAP) approach
 REST approach

22

22

© Swinburne University of Technology 11

SWE30003 Software Architectures and S1 2024
Design

Web Architectural Styles – SOA

Service Oriented Architecture

 SOA is fundamentally of client-server style, and based on
 the interaction between decoupled services and/or end-user applications
 associated with messages & governed by policies.
 services distributed in a network, via published and discoverable
interfaces.
Service - Searchable directory where service
descriptions can be published and
Client searched.
- Contains sufficient information
Roles for the service requestor to contact,
Find or bind to, the service provider and
thus make use of the services it
3 2 provides.

Service
Description
Service
Service
Service
Publish
Provider Service
1 Registry
Description
23
23

Web Architectural Styles

Web Architectural Styles

Fundamentally, client-server…. Sub-styles:
 Method-oriented RPC (Remote Procedure Call)
 Interface: Method, parameters
 Interaction: synchronous request-response, request-acknowledge

 Message-oriented (aka Document style)

 Interface: Domain specific operation, Message type
 Interaction: Various synch/asynch, request-response, one way, solicit-notify

 Resource-oriented
 Interface: generic CRUD, Resource id, Media type
 Interaction: synchronous request-response, request-acknowledge

 Event-oriented
24
 Interface: event type
 Interaction: Subscribe-notify, publish-subscribe-notify
24

© Swinburne University of Technology 12

SWE30003 Software Architectures and S1 2024
Design

Web Architectural Styles - RPC

Remote Procedure Calls - an oo/component approach

 Object/component-oriented Client Remote
procedure code
Server Remote
procedure

approach to distributed Application Application

computing e.g. CORBA code code

 Application elements use a

request/wait-for-reply
Stub code Stub code

(synchronous) model of RPC run-time RPC run-time

communication. library library

 RPC-style programming
leads to tight coupling of
interfaces and applications. Network

 In an RPC environment each application needs to know the intimate

details of the interface of every other application – the number of
methods it exposes & the details of each method signature it exposes.
25

25

Web Architectural Styles - Messaging

Asynchronous request/reply messaging

 Most asynchronous messaging mechanisms follow the “fire-and-forget”
messaging principle where the sending application can conduct its work as
usual once a message was asynchronously sent.
 The sending application assumes that the message will arrive safely at its
destination at some point in time.
 This mode messaging does not preclude the necessity to perform
request/reply operations.
request request

message Message channel message

reply reply

message Message channel message

Requester Replier

26

26

© Swinburne University of Technology 13

SWE30003 Software Architectures and S1 2024
Design

Web Architectural Styles – Message-oriented

Message-oriented Middleware
 MOM is an infrastructure that involves the passing of data between
applications using a common communication channel that carries
self-contained messages.
 Messages are sent and received asynchronously.
 The messaging system (integration broker) is responsible for
managing the connection points between clients & for managing
multiple channels of communication between the connection points.
Client Client Server
Message Message
Application logic
publication notification
MOM MOM MOM

MOM Integration Broker

27

27

Web Architectural Styles – Resource-oriented

Resource-oriented Architecture
 Resources exposed on a network
 Resources uniquely identified
 Application is a series of linked resource updates between clients
and servers
 Resource examples
CRUD:
 something returned by an SQL query Create, Read,
 text or media file Update, Delete
 a transaction
 a web site
 a downloadable program
 ...

28

28

© Swinburne University of Technology 14

SWE30003 Software Architectures and S1 2024
Design

Web Architectural Styles – Event-oriented

EDA – Event Driven Architectures

 Event emitters and consumers
 Promotes further decoupling of business processes
 Same event can be consumed by a number of other
(possibly anonymous) processes.
 Event emitter does not care who consumes the event
 Fits well with declarative rules based approach to
defining business processes (as distinct from an
imperative activity based approach as in BPEL (ie, the
WS composition language))
http://www.infoq.com/presentations/SOA-Business-Autonomous-Components
29

29

How does SOA help achieve loose coupling?

Type of Coupling Problem Description Reduced by

Functional One module relies on the Well defined interface/API describing inputs and
internal workings others outputs
Interface Interfaces reflect the Avoid detailed mandatory parameters;
implementation details Use more general methods and message
passing (do not get too fine-grained)
Data Structure Data passed between Explicitly define formats, e.g XML in interface;
modules reflects internal Allow multiple representations e.g.mime-types;
representations, ‘Vertical’ standards that define semantics of
or is over-constrained messages
Temporal Client blocked while Asynchronous messages; Explicitly define
waiting response behaviour in interface e.g. abstract BPEL;
Process over-constrained Interaction via events / event-driven processes
Address/URI Addresses change Do not hard code references;
Providers change Virtualise services;
URI patterns change Use middleware directory services

30

30

© Swinburne University of Technology 15

SWE30003 Software Architectures and S1 2024
Design

Content

 Software services / web services

 Some concepts you need to understand
 Service oriented architecture (SOA)
 Web application architectural styles and middleware
 WS* (SOAP) approach
 REST approach
 Microservices

31

31

Web Application (Standard) Approaches

 Web Service Standards – “WS*”
 SOAP message and WSDL interface descriptions
 Stack of other WS* Standards (UDDI, WS-Transaction, WS-Security, … )
 Service composition and orchestration
 e.g. BPEL – Business Process Execution Language
 Middleware based - many frameworks and technologies being developed
 e.g. Web Sphere, JBoss, Apache Axis, WSO2, …

 REST– based (Representational State Transfer)

 Light-weight approach, inter-operability based on HTTP
 View machine clients like automatic ‘browsers’
 Resource/data centric
 http://www.infoq.com/presentations/The-Counterintuitive-Web

 Microservices: functions (data) as service …

32

32

© Swinburne University of Technology 16

SWE30003 Software Architectures and S1 2024
Design

Technologies for Web Architectures

Different Web ‘protocol patterns’ suit various architectural styles

 RPC
 WS* (SOAP, WDSL, …)
 Message-oriented
 RESTful / Microservices
 Resource-oriented
 Event-oriented

Note: There are many Web applications that do

not follow these standard approaches 33

33

????
Which architectural style is the most “decoupled”?
Which architectural style is the hardest to change /
evolve? a.k.a “Fragile”

Coupling of reference address, interface, implementation, behaviour, …

Fragility - What breaks when something is changed?

34

34

© Swinburne University of Technology 17

SWE30003 Software Architectures and S1 2024
Design

Content

 Software services / web services

 Some concepts you need to understand
 Service oriented architecture (SOA)
 Web application architectural styles and middleware
 WS* (SOAP) approach
 REST approach
 Microservices

35

35

WS* (SOAP) Architectures

 Evolution of the enterprise computing middleware approach
 CORBA, MoM, ESB
 * = Standards needed, so enterprise system can interoperate
 Description, Discovery, QoS, Security, Transactions, etc.

 “Big” Web Services – many big vendors developing middleware

products to support standards based approach
 IBM, BEA, Microsoft, JBoss, WSO2, ...
 An application protocol (SOAP), views/uses HTTP as a
transport protocol to carry SOAP messages
 Although almost always HTTP, such SOAP services can use other
transports i.e. they are not necessarily “Web” services.
 Calls/Messages defined and exchanged by machine using XML
36
Schema
36

© Swinburne University of Technology 18

SWE30003 Software Architectures and S1 2024
Design

Message Exchange Patterns

 Four common types of operations that represent possible
combinations of input and output messages
 Support for both push and pull interaction models at the
interface level. One-way Messaging

 Not just client-server Service consumer SOAP Message

request - response end-point
Service provider
end-point
Request/Response Messaging
SOAP Request
SOAP Response
Service consumer Service end-point
end-point
Notification Messaging
SOAP Notification
Service consumer Service end-point
end-point
Solicit/Response Messaging
SOAP Request Message
SOAP Answer Message
37
Service end-point

37

Web Services and Messaging

 WS* approach defines a standard messaging format
called SOAP (originally defined as Simple Object
Access Protocol)
 Can use multiple application protocols for transport:
 HTTP, HTTPS, SMTP, …

 WSDL (service interface description) is designed to

work with SOAP

38

38

© Swinburne University of Technology 19

SWE30003 Software Architectures and S1 2024
Design

WS Technology Stack implementation of SOA

 Web services are implemented by a collection of several
related technologies & standards.
Choreography - CDL4WS Business
Orchestration - BPEL4WS Processes
Management Transactions
Quality of
WS-Reliability WS-Security Coordination Service
Context
UDDI Discovery
WSDL Description
SOAP
Message
XML
HTTP,JMS, SMTP Transport

WS* Standards are defined in XML Schema 39

39

WSDL – Web Service (Interface) Description

 Interface descriptions
 Structure of WSDL documents
 Abstract part
 Concrete part

40

40

© Swinburne University of Technology 20

SWE30003 Software Architectures and S1 2024
Design

An example:
in programming language style (illustration only)
Service StokeQuote {
//types
struct TradePriceRequestType { //RPC
string tickerSymbol;
};
struct TradePriceType{
float price;
};
Interface StokeQuotePortType {
void GetLastTradePrice
(in TradePriceRequestType GetLastTradePriceInput,
out TradePriceType GetLastTradePriceOutput);
……
};
};
41

41

Web services in context

 For “use of service” to happen, the consumer needs to understand
and the provider needs to tell:
 What the service can do – functionality: (by WSDL …)
 How good the service can do it – qualities: (partly by other WS standards …)
 How to use the service – usage: (partly by WSDL …)
 How can we achieve this “understanding”:
 Self-describing Web service interface (in WSDL, and …)
 Platform independent (in XML)
 Provider / Registry tells …
 Consumer understands …

42

42

© Swinburne University of Technology 21

SWE30003 Software Architectures and S1 2024
Design

Web Services Description Language

 The Web Services Description Language (WSDL) is the

XML-based service representation language used to
describe the details of the complete interfaces exposed
by Web services and thus is the means to accessing a
Web service.
 For instance, neither the service requester nor the provider
should be aware of each other’s technical infrastructure,
programming language or distributed object framework (if
any).
 WSDL is a platform-independent description meant to
be created and read by machines (not hand-written)
 Generated from code objects or ide design tools

43

43

Structure of WSDL documents

 WSDL documents can be separated into distinct sections:
 The service interface definition describes the general web service
interface structure. This contains all the operations supported by the
service, the operation parameters and abstract data types.
 The service implementation part binds the abstract interface to a
concrete network address, to a specific protocol and to concrete data
structures.
 This enables each part to be defined separately and
independently, and reused by other parts
 The combination of these two parts contains sufficient
information to describe to the service requester how to invoke
and interact with the web service at a provider’s site.

44

44

© Swinburne University of Technology 22

SWE30003 Software Architectures and S1 2024
Design

<wsdl:definitions name="PurchaseOrderService"
targetNamespace="http://supply.com/PurchaseService/wsdl"
xmlns:tns="http://supply.com/ PurchaseService/wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" Example of
xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
Abstract data type
Abstract WSDL
<xsd:schema definitions
targetNamespace=http://supply.com/PurchaseService/wsdl>
Interface definition
<xsd:complexType name="CustomerInfoType">
<xsd:sequence>
<xsd:element name="CusNamer" type="xsd:string"/>
<xsd:element name="CusAddress" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="POType">
<xsd:sequence>
<xsd:element name="PONumber" type="integer"/>
<xsd:element name="PODate" type="string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="InvoiceType">
<xsd:all>
<xsd:element name="InvPrice" type="float"/>
<xsd:element name="InvDate" type="string"/>
</xsd:all>
</xsd:complexType>
</xsd:schema> Data that is sent
</wsdl:types>
<wsdl:message name="POMessage">
<wsdl:part name="PurchaseOrder" type="tns:POType"/>
< wsdl:part name="CustomerInfo" type="tns:CustomerInfoType"/>
</wsdl:message>
<wsdl:message name="InvMessage"> Data that is returned
<wsdl:part name="Invoice" type="tns:InvoiceType"/>
</wsdl:message> Port type with
<wsdl:portType name="PurchaseOrderPortType"> one operation
<wsdl:operation name="SendPurchase">
<wsdl:input message="tns:POMessage"/>
An operation with
<wsdl:output message="tns:InvMessage"/>
request (input) &
</wsdl:operation>
response (output)
45
</wsdl:portType>
</wsdl:definitions> message

45

<wsdl:definitions> . …
<import namespace="http://supply.com/PurchaseService/wsdl"
location="http://supply.com PurchaseService/wsdl/PurchaseOrder-interface.wsdl"/>
<!-- location of WSDL PO interface from Listing-1-->
<!-- wsdl:binding states a serialisation protocol for this service -->
<!-- type attribute must match name of portType element in Listing-1-->
<wsdl:binding name="PurchaseOrderSOAPBinding" Listing 2:
type="tns:PurchaseOrderPortType">
Example of WSDL
<!-- leverage off soapbind:binding synchronous style --> Implementation
<soapbind:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http/"/>

<wsdl:operation name="SendPurchase"> Bind an abstract operation

to this implementation &
<!-- again bind to SOAP -->
<soapbind:operation
soapAction="http://supply.com/ PurchaseService/wsdl/ SendPurchase" style="rpc"/>

<!-- furthur specify that the messages in the wsdl:operation use SOAP -->
<wsdl:input> map the abstract
<soapbind:body use="literal" input & output messages
namespace="http://supply.com/PurchaseService/wsdl"/> to these concrete messages
</wsdl:input>
<wsdl:output>
<soapbind:body use=“literal"
namespace="http://supply.com/ PurchaseService/wsdl"/>
</wsdl:output>

</wsdl:operation>
</wsdl:binding>
Service name
<wsdl:service name=“PurchaseOrderService">
<wsdl:port name=“PurchaseOrderPort" binding="tns:PurchaseOrderSOAPBinding">
<!-- give the binding a network endpoint address or URI of service --> Network address of service
<soapbind:address location="http://supply.com:8080/PurchaseOrderService"/>
</wsdl:port> 46
</wsdl:service>
</wsdl:definitions>

46

© Swinburne University of Technology 23

SWE30003 Software Architectures and S1 2024
Design

SOAP (Simple Object Access Protocol)

 an XML-based communication protocol for exchanging
messages between computers, regardless of their
operating systems or programming environments
 Overcomes the problems of conventional distributed
object models
 Does not require uniform object model across applications
 Loose-coupling/strong encapsulation for applications (no
internal object ref)
 Designed to work with WSDL http://schemas.xmlsoap.org/wsdl/

 Use HTTP - work over firewalls or proxy servers, e.g, most

firewalls are configured to allow Hypertext Transfer Protocol
(HTTP) to pass across
47

47

What is SOAP?
 The standard messaging protocol used by Web services
 Primarily for inter-application communication (‘server’ to ‘server’)
 Use an XML-based scheme for encoding message (request and response) data
 Typically uses HTTP as a means for transport

service requestor service provider

application object application object

(client) (service provider)

SOAP-based SOAP-based
middleware middleware
SOAP messages
exchanged on top of,
HTTP, SMTP, JMS or
other transport

converts procedure calls to/from XML

messages sent through HTTP or other
protocols.
48

48

© Swinburne University of Technology 24

SWE30003 Software Architectures and S1 2024
Design

SOAP as a lightweight protocol

 SOAP is a lightweight
protocol that allows Web Service Web Service
applications to pass
messages and data back and
forth between disparate WSDL Interface WSDL Interface
systems in a distributed
environment enabling remote SOAP Messages

method invocation. Transfer Protocol (e.g., HTTP)

TCP/IP Protocol Stack

 Lightweight: SOAP protocol possesses only two fundamental properties. It can :

 send and receive HTTP (or other) transport protocol packets, and
 process XML messages.

 Supports both RPC and message (document) style interaction

 This can be contrasted with the heavyweight protocols such as ORPC protocols.
Designed to work with these.
Guiding principle:
“First invent no new technology”
http://msdn.microsoft.com/en-us/magazine/bb985060.aspx
49

49

Distributed messaging with SOAP

Web-service Web-service
requester provider
4
Client Web-service
Application Application
3
1 6
Web-service
implementation
infrastructure

SOAP message SOAPserver

XML document
5 2

Network Transport Network Transport

Protocol Protocol
(HTTP) (HTTP)

firewall

Distributed messaging
using SOAP

50

50

© Swinburne University of Technology 25

SWE30003 Software Architectures and S1 2024
Design

SOAP messages
<Envelope>
<Envelope>
 SOAP is based on message exchanges.
 Messages are seen as envelopes where the 0..1 1
application encloses the data to be sent. <Header> <Body>
<Header> <Body>
 A SOAP message consists of an <Envelope>
element containing an optional <Header> and a 1..* 1..*
mandatory <Body> element. <Header <Body
<Header <Body
block> entry>
 The contents of these elements are application block> entry>

defined and not a part of the SOAP specifications.

SOAP envelope
 A SOAP <Header> contains blocks of information
relevant to how the message is to be processed. SOAP header
This helps pass information in SOAP messages
header block
and it is not application payload.
 The SOAP <Body> is where the main end-to-end
information conveyed in a SOAP message must
be carried. SOAP body

body entry

51

51

Example of RPC-style SOAP body

<env:Envelope
xmlns:SOAP=“http://www.w3.org/2003/05/soap-envelope”
xmlns:m="http://www.plastics_supply.com/product-prices">
<env:Header>
<tx:Transaction-id
xmlns:t=”http://www.transaction.com/transactions”
env:mustUnderstand='1'>
512
</tx:Transaction-id>
</env:Header>
<env:Body>
<m:GetProductPrice>
<m:product-id> 450R6OP </m:product-id >
</m:GetProductPrice >
</env:Body>
</env:Envelope>

Corresponding method invocation in programming language style:

GetProductPrice(“450R6OP”); 52

52

© Swinburne University of Technology 26

SWE30003 Software Architectures and S1 2024
Design

Example of RPC-style SOAP response message

<env:Envelope
xmlns:SOAP=“http://www.w3.org/2003/05/soap-envelope”
xmlns:m="http://www.plastics_supply.com/product-prices">
<env:Header>
<--! – Optional context information -->
</env:Header>
<env:Body>
<m:GetProductPriceResponse>
<m:product-price> 134.32 </m:product-price>
</m:GetProductPriceResponse>
</env:Body>
</env:Envelope>

Corresponding method invocation in programming language style:

134.32 53

53

Implementing WS* Web Services

 Design and implement an OO software system
 Generate WSDL interface
 Deploy service
 Publish WSDL interface (API)
 Other services/systems use

54

54

© Swinburne University of Technology 27

SWE30003 Software Architectures and S1 2024
Design

Code to WSDL

55

55

Design tool to
WSDL

56

56

© Swinburne University of Technology 28

SWE30003 Software Architectures and S1 2024
Design

Content

 Software services / web services

 Some concepts you need to understand
 Service oriented architecture (SOA)
 Web application architectural styles and middleware
 WS* (SOAP) approach
 REST approach
 Microservices

57

57

REST based architectures

 Purist and Hybrid approaches
 RESTful Web Services (purists)
 HTTP as an application protocol
 ‘Resource-oriented’ architecture
 Everything referenced as a URI

 HTTP ‘verbs’ have specific meaning  uniform CRUD interface

 GET – retrieve information on a resource
 POST – Create a new resource
 PUT – Modify an existing resource
 DELETE – Delete an existing resource
 Also use HEAD (get meta-data), OPTIONS (check which verbs supported)

 E.g. Most Yahoo’s web services, Amazon’s S3 (Simple Storage Service)

58

58

© Swinburne University of Technology 29

SWE30003 Software Architectures and S1 2024
Design

REST – a resource-oriented architecture

 Representational State Transfer
 Expose resources to clients on a networked system
 Everything referenced as a URI

 Client-server architecture
 Application state is driven by the client’s updating resources
across the resource network using links provided by the server(s)
 “Hypermedia is the engine of state”

 What is a resource? Not just relational XML infosets

 something returned by an SQL query, text file, media file,
a transaction, a queue, a web site, a downloadable program, ...
 REST is a style or “design guideline” – not a standard
59

59

REST – Resource identification

 All resources (services) referenced by a unique URI
 e.g. GET

60

60

© Swinburne University of Technology 30

SWE30003 Software Architectures and S1 2024
Design

REST Methods – strict HTTP

 RESTful Web Services (purist)
 HTTP as an application protocol
 HTTP ‘verbs’ have specific meaning  uniform CRUD interface for keeping
resources updated:
 GET – retrieve information on a resource
 POST – Create a new resource
 PUT – Modify an existing resource
 DELETE – Delete an existing resource
 Also use HEAD (get meta-data), OPTIONS (check which verbs supported)

 E.g. Most Yahoo’s web services, Amazon’s S3 (Simple Storage Service)

61

61

REST presents a uniform interface

Graphic courtesy of CSE UNSW

62

62

© Swinburne University of Technology 31

SWE30003 Software Architectures and S1 2024
Design

REST Example
 Step 1 : Client asks for a list of parts

Graphic courtesy of CSE UNSW

63

63

REST Example
 Step 2. Given the part number ….

Graphic courtesy of CSE UNSW

64

64

© Swinburne University of Technology 32

SWE30003 Software Architectures and S1 2024
Design

REST example
 Placing an order (i.e. creating a new order resource)

POST http://www.parts-depot.com/order/00345 HTTP/1.1

Graphic courtesy of CSE UNSW

65

65

REST example
 Updating a resource

Graphic courtesy of CSE UNSW

66

66

© Swinburne University of Technology 33

SWE30003 Software Architectures and S1 2024
Design

Implementing REST Web Services

 Design and implement an OO software system (main
class with CRUD)
 Deploy service (with API)
 Publish API interface
 Other services/systems use

67

67

WS* vs RESTful?
WS* RESTful
Easy to understand approach Complex Simpler
Easy to implement Depends... Depends...
Interface definition Specific Generic
Interface Contracts Yes - WSDL Not yet (WADL?)
Specific to the Web No Yes
Implementation of SOA Yes Not really
Scalable Hmmm.... Yes
Addresses enterprise concerns (e.g. Yes Not directly
transactions, end-end security)
Orientation Method Resource

68

68

© Swinburne University of Technology 34

SWE30003 Software Architectures and S1 2024
Design

Content

 Software services / web services

 Some concepts you need to understand
 Service oriented architecture (SOA)
 Web application architectural styles and middleware
 WS* (SOAP) approach
 REST approach
 Microservices

69

69

Microservices
An architectural approach - Some perspectives
 A type of SOA
 Functional perspective
- Business functionality/capability oriented partition
 Modular
 Small (capability) & light-weight (technology: REST)
 Self-contained & deployable
 Oriented towards development, delivery & deployment
 Scalable
 Granularity vs Complexity …
70

70

© Swinburne University of Technology 35

SWE30003 Software Architectures and S1 2024
Design

Question to Answer – Week 10

71

71

Required Reading Week 11

 Len Bass, Paul Clements, and Rick Kazman, Software

Architecture in Practice (4th Edition), Addison-Wesley,
2021, Chapter 22. OR,
 Len Bass, Paul Clements, and Rick Kazman, Software
Architecture in Practice (3rd Edition), Addison-Wesley,
2013, Chapter 18.

72

72

© Swinburne University of Technology 36