![[SOLVED] distributed system scheme flex database Software Construction & Design 1](https://assignmentchef.com/wp-content/uploads/2022/08/downloadzip.jpg)
Software Construction & Design 1
The University of Sydney Page 1
Software Construction and
Design 2
SOFT3202 / COMP9202
Enterprise & GoF Design
Patterns
School of Information Technologies
Dr. Basem Suleiman
The University of Sydney Page 2
Copyright Warning
COMMONWEALTH OF AUSTRALIA
Copyright Regulations 1969
WARNING
This material has been reproduced and communicated to
you by or on behalf of the University of Sydney
pursuant to Part VB of the Copyright Act 1968 (the
Act ).
The material in this communication may be subject
to copyright under the Act. Any further copying or
communication of this material by you may be the
subject of copyrightprotection under
the Act.
Do not remove this notice.
The University of Sydney Page 3
Agenda
GoF Design Patterns
State
Service Oriented Architecture
Web Services
SOAP-based Services
Representation State Transfer (REST)
RESTful Services
The University of Sydney Page 4
State Design Pattern
GoF
The University of Sydney Page 6
State Design Pattern
Object behavioral
Object relationships which can be changed dynamically at run-time
How a group of objects can collaborate to perform a task that no single
object can do alone
Intent
Allow an object to change its behavior when its internal state changes
Think finite-state-machine
The University of Sydney Page 7
Motivating Scenario
TCP network connection
States: Established, Listening and Closed
TCP connection responds based on its current state
The University of Sydney Page 8
State Pattern When to Use
The state of n object drives its behavior and change its behavior
dynamically at run-time
Operations have large, multipart conditional statements that depend on the
objects state
Repeated conditional structure
The University of Sydney Page 9
State Pattern Structure
By State_Design_Pattern_UML_Class_Diagram.png: JoaoTrindade (talk)Original uploader was JoaoTrindade at en.wikipediaderivative work: Ertwroc (talk) State_Design_Pattern_UML_Class_Diagram.png, CC BY-SA 3.0,
https://commons.wikimedia.org/w/index.php?curid=10234908
The University of Sydney Page 10
State Pattern Participants
Context (TCPConnection)
Defines the interface of interest to clients
Maintains an instance of a ConcreteState subclass that defines the current state
State (TCPState)
Defines an interface for encapsulating the behavior associated with a certain
state of the Context
ConcreteState subclasses (TCPEstablished, TCPListen, TCPClosed)
Each subclass implements a behavior associated with a state of the Context
The University of Sydney Page 11
State Pattern Collaborations
Context delegates state-specific requests to the current ConcreteState
object
A context may pass itself as an argument to the State object handling the
request, so the State object access the context if necessary
Context is the primary interface for clients
Clients can configure a context with State objects, so its clients dont have to
deal with the State objects directly
Either Context or the ConcreteState subclasses can decide which state
succeeds another and under what circumstances
The University of Sydney Page 12
State Pattern Consequences
Localizes state-specific behavior for different states
Using data values and context operations make code maintenance difficult
State distribution across different sub-classes useful when there are many states
Better code structure for state-specific code (better than monolithic)
It makes state transition explicit
State transitions as variable assignments
State objects can protect the context from inconsistent state
State objects can be shared
When the state they represent is encoded entirely in their type
The University of Sydney Page 13
State Pattern Implementation (1)
Defining the state transitions
Let the state subclasses specify their successor state to make the transition
(decentralized)
Achieves flexibility easy to modify and extend the logic
Introduces implementation dependencies between subclasses
Table-based state transitions
Look-up table that maps every possible input to a succeeding state
Easy to modify (transition data not the program code) but:
Less efficient than a functional call
Harder to understand the logic (transition criteria is less explicit)
Difficult to add actions to accompany the state transitions
The University of Sydney Page 14
State Pattern Implementation (2)
When to create and destroy state objects?
Pre-create them and never destroy them
Useful for frequent state changes (save costs of re-creating states)
Context must keep reference to all states
Only when they are needed and destroyed them thereafter
States are not known at run-time and context change states frequently
The University of Sydney Page 15
State Pattern Implementation (3)
Using dynamic inheritance
Changing the objects class at run-time is not possible in most OO languages
Delegation-based languages allow changing the delegation target at run-time
The University of Sydney Page 16
State Pattern Code Example
The University of Sydney Page 17
State Pattern Code Example
The University of Sydney Page 18
State Pattern Code Example
What is the output of StateDemo?
The University of Sydney Page 20
State Pattern Related Patterns
Flyweight
Explains when and how state objects can be shared
Singleton
State object is often implemented as Singleton
The University of Sydney Page 21
Service-Oriented
Architecture (SOA)
The University of Sydney Page 22
Service-Oriented Architecture (SOA)
a style of software design where services are provided to the other components by
application components, through a communication protocol over a network
Wikipedia (May 2019)
Paradigm, approach or style
Can help to architect applications so that certain quality attributes are satisfied
Services are the core of this approach
The University of Sydney Page 23
What Is A Service?
A unit of abstracted functionality that can be accessed remotely
and consumed through abstract interface
Logically represents a business activity/functionality with a specified
outcome
Self-contained
Abstracts implementation details
May compose of one or more services
The University of Sydney Page 24
A Service-based Application
The University of Sydney Page 25
SOA A Service-based Application
(MVS/CICS)
Bank
(Win2K3/
COM+)
Credit Card
processor
Linux/
EJB
Supplier 2
(Win2K3
.NET)
Supplier 1
(Solaris/
CORBA)
Shipper 2
Smart client app
Browser-based client
On-line retail
application
(J2EE/IIOP/JMS) Web Server
Reseller
Win2K3
EJB
User
authentication
(Win2K/
MQ)
Shipper 1
Building large-scale integrated
applications from services
Specific enough to have clear focus
Integration and communication
Platform independence
Abstracted from end users
Reliability and robustness
Avoid rewriting legacy code
The University of Sydney Page 26
SOA Principles
Boundaries are explicit
Services are external, crossing boundaries has costs and implications
Services are autonomous
May be outside your control, can change
Share schema and contract
Not classes and implementations
Policy-based compatibility
Requirements stated in policies, not in code
The University of Sydney Page 27
Web Services
SOAP Services
The University of Sydney Page 28
Web Services
Relatively standardized mechanism by which one piece of software
application can connect and communicate with another using web protocols
It provides a simple and open way of integrating functions or data from
various systems
It can be used within an organization and/or across the public Internet
At least two implementations: SOAP-based vs. RESTful services
Original design of Web Services is very application-centric in contrast to
the resource-centric Web and REST style
COMP5347 Web Application Development
The University of Sydney Page 29
Web Service Specifications
Simple Object Access Protocol (SOAP): a messaging protocol for transferring
information (XML format)
Web Service Description Language (WSDL): A standard for describing Web
services (XML format)
Interfaces, methods, parameters, request, response
Generated and consumed by tools
Universal Description, Discovery and Integration (UDDI): a registry and protocol
for publishing and discovering web services
Like white, Yellow and Green pages
Not really used
Other specifications include Security, Privacy, Reliable Messaging, Transaction,
Interoperability
Web service specifications are occasionally referred to collectively as WS-*
COMP5347 Web Application Development
The University of Sydney Page 30
Web Service SOAP-based Services
A component that offers services that can be accessed through messages that
follow some particular XML-based standards
XML messages in the protocol
XML definitions of services
Pass around XML documents
Building on other XML standards
All human readable (for some subset of humans)
These messages may be carried over HTTP
Standards are managed through W3C
Standardise only what goes on the wire
No programming models or APIs
The University of Sydney Page 31
Terminology
Sender
Receiver
Intermediary
A receiver that then sends the message onwards
Ultimate Receiver
The receiver that actually provides the service
Does not send the message on any further
The University of Sydney Page 33
Web Services Consumption
Find a service
Find out how to call it
What information it needs
Where it is located
Ask it to do something for you
Invoke a service method
And add a few useful services
Transactions? Security? Reliability?
The University of Sydney Page 34
Calling A Service SOAP
Envelope (Mandatory)
Marks the start and end of a
message
Body (Mandatory)
Data for the actual message
or document being sent
Header (Optional)
General information about
message e.g. authentication
and transaction management
SOAP Simple Object Access Protocol!
Originally simple remote procedure calls using XML-
formatted protocol
Envelope, header, body
Extensible protocol
Add new header elements for new semantics
Very widely accepted standard
The University of Sydney Page 35
WSDL Structure
WSDL Ports
Describe the operations that can be performed and messages that
are involved
WSDL Messages
Describes the parts of a messages. A part can be seen as parameters
of a message
WSDL Types
Defines the data types of used by the web service
WSDL Bindings
Describes the message format and protocol details for each port
The University of Sydney Page 36
SOAP Example Stock Quote
GET /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml
Content-Length: nnnn
SOAPMethodName: Stock-Namespace-URI#GetLastTradePrice
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnnn
The University of Sydney Page 37
WSDL Structure
definition of types..
definition of a message.
definition of a port.
definition of a binding.
The University of Sydney Page 38
Publishing and Consuming a Service
The University of Sydney Page 39
SOAP-based Services Workflow
The University of Sydney Page 40
SOAP Services Performance Factors
Processor time for XML encoding/decoding
Is XML slower than binary alternatives?
Number and size of msgs passed around
Does verbosity cost performance?
Proc time taken by transport protocols
TCP/IP and HTTP
Network delays
Switches, routers,
Others
The University of Sydney Page 41
Web Services Stack
Connected Applications
Messaging
XML
Transports
Secure Reliable Transacted
M
e
ta
d
a
ta
Management
Business
Process Devices Mobile
P2P EAI B2B Grid
The University of Sydney Page 42
Representation State
Transfer (REST), RESTful
Services
The University of Sydney Page 43
Representation State Transfer (REST)
Defined by Roy Fielding in his 2000 thesis
REpresentational State Transfer (REST, RESTful)
Web and agile developer community has been working on ways to make a
Web for programs rather than people
Adopt ideas that make WWW successful, but suited to consumption by programs
rather than human readers
Web-friendly: use web technologies in ways that match what the Web expects
The University of Sydney Page 44
REST Architectural Style
REST is an architectural style rather than a strict protocol
REST-style architectures consist of clients and servers
Requests and responses are built around the transfer of representations of resources
A resource can be essentially any coherent and meaningful concept that
may be addressed
A representation of a resource is typically a document that captures the
current or intended state of a resource
Based on Roy Fieldings doctoral dissertation, rephrased by Wikipedia http://en.wikipedia.org/wiki/Representational_State_Transfer
COMP5347 Web Application Development
http://en.wikipedia.org/wiki/Client_(computing)
http://en.wikipedia.org/wiki/Server_(computing)
http://en.wikipedia.org/wiki/Resource_(Web)
http://en.wikipedia.org/wiki/Representation_(systemics)
The University of Sydney Page 45
REST The Basic Idea
HTTP Client
(e.g. web browser)
Web Server Database
GET /book/222
POST /order
301 location: /order/612
PUT /order/612
SELECT *
FROM Books
WHERE isbn=222
INSERT
INTO Orders
UPDATE Orders
WHERE id=612
SET
[adapted from Cesare Pautasso, http://www.pautasso.info, 2008]
The University of Sydney Page 47
REST Stateless vs. Stateful
http://www.ibm.com/developerworks/webservices/library/ws-restful/
COMP5347 Web Application Development
http://www.ibm.com/developerworks/webservices/library/ws-restful/
The University of Sydney Page 48
REST Design Principles
1. Resource Identification through URI
2. Uniform Interface for all resources(HTTP verbs)
GET (Query the state)
PUT (Modify (or create)
POST (Create a resource, with system choosing the identifier)
DELETE (Delete a resource)
3. Self-Descriptive Messages through Meta-Data
4. Hyperlinks to define the application state
Address the resources explicitly in the request message
The University of Sydney Page 49
REST Tenets
Resource-based rather than service-oriented
Addressability: interesting things (resources) should have names
Statelessness: no stateful conversations with a resource
Representations: a resource has state representation
Links: resources can also contain links to other resources
Uniform Interface: HTTP methods that do the same thing
The University of Sydney Page 51
REST Resources
A resource is something interesting in your system
Anything like Blog posting, printer, a transaction, others
Requests are sent to URIs (nouns)
Choosing the resources and their URIs is the central design decision for making a
RESTful service
The operations (verbs) are always the same simple HTTP ones (get,
post, put) and they act as expected
The University of Sydney Page 52
REST Resource Representations
We deal with representations of resources
Not the resources themselves
Pass-by-value semantics
Representation can be in any format
Representations like JSON or XML are good for Web-based
services
Each resource has one or more representations
Each resource implements the uniform HTTP interface
Resources URIs
The University of Sydney Page 53
REST Resource Architecture
Physical Resources
Logical Resources
Uniform Interface
(Web Server)
Resource
Representation
(e.g. XML document)
Consumer
(Web Client)
The University of Sydney Page 54
REST Uniform Resource Identifier (URI)
Internet Standard for resource naming and identification
Examples:
http://tools.ietf.org/html/rfc3986
https://www.google.com/search?q=rest&start=10
REST advocates the use of nice URIs
In most HTTP stacks URIs cannot have arbitrary length (4Kb)
URI Scheme Authority Path
Query
The University of Sydney Page 55
REST Resource URIs
URIs should be descriptive?
Convey some ideas about how the underlying resources are arranged
http://spreadsheet/cells/a2,a9
http://jim.webber.name/2007/06.aspx
URIs should be opaque?
Convey no semantics, cant infer anything from them
The University of Sydney Page 56
REST Links
Connectedness is good in Web-based systems
Resource representations can contain other URIs
Resources contain links (or URI templates) to other resources
Links act as state transitions
Think of resources as states in a state machine
And links as state transitions
Application (conversation) state is captured in terms of these states
Server state is captured in the resources themselves, and their
underlying data stores
The University of Sydney Page 57
REST The HTTP Verbs
Retrieve a representation of a resource: GET
Get metadata about an existing resource: HEAD
Create a new resource: PUT to a new URI,
or POST and the resource will get a new system-chosen URI
Modify an existing resource: PUT to an
existing URI
Delete an existing resource: DELETE
See which of the verbs the resource
understands: OPTIONS
The University of Sydney Page 58
Resource Types
Most of the time we can differentiate between collection type of resources and
individual resource
Revisions and revision
Articles and article
This can be nested and developers/architect often decide the nesting direction
/movies/ForrestGump/actors/TomHanks
/directors/AngLee/movies/LifeOfPi
COMP5347 Web Application Development
The University of Sydney Page 59
REST Request URLs and Methods
Action URL path Parameters Example
Create new revision /revisions http://localhost:3000/revisions
Get all revisions /revisions http://localhost:3000/revisions
Get a revision /revisions revision_id http://localhost:3000/revisions/123
Update a revision /revisions revision_id http://localhost:3000/revisions/123
Delete a revision /revisions revision_id http://localhost:3000/revisions/123
COMP5347 Web Application Development
Request Method Use case Response
POST Add new data in a collection New data created
GET Read data from data source Data objects
PUT Update existing data Updated object
DELETE Delete an object NULL
The University of Sydney Page 60
Uniform Interface Principle (CRUD Example)
CRUD REST
CREATE PUT (user chooses the URI) or POST
(system chooses the URI)
Initialize the state of a new resource
READ GET Retrieve the current state of a resource
UPDATE PUT Modify the state of a resource
DELETE DELETE Clear a resource; afterwards the URI is no longer
valid
The University of Sydney Page 61
GET Semantics
GET retrieves the representation of a resource
Should not affect the resource state (idempotent)
Shared understanding of GET semantics
Dont violate that understanding!
The University of Sydney Page 62
POST Semantics
POST creates a new resource
But the server decides on that resources URI
Common human Web example: posting to a blog
Server decides URI of posting and any comments made on that post
Programmatic Web example: creating a new employee record
And subsequently adding to it
The University of Sydney Page 63
POST Request and Response
Request
POST / HTTP/1.1
Content-Type: application/xml
Host: localhost:8888
Content-Length: .
Verb, path, and HTTP
version
Content type (XML)
Content (again XML)
Response
201 CREATED
Location: /orders/jwebber/ABCD/2007-07-08-13-50-53
The University of Sydney Page 64
PUT Semantics
PUT creates a new resource but the client decides on the URI
Providing the server logic allows it
Also used to update existing resources by overwriting them in-place
Dont use POST here
Because PUT is idempotent!
The University of Sydney Page 65
PUT Request
PUT /orders/jwebber/ABCD/2007-07-08-13-50-53 HTTP/1.1
Content-Type: application/xml
Host: localhost:8888
Content-Length: .
Verb, path and HTTP
version
Updated content
(higher buy price)
The University of Sydney Page 66
PUT Response
200 OK
Location: /orders/jwebber/ABCD/2007-07-080-13-50-53
Content-Type: application/xml
Minimalist response might
contain only status and location
The University of Sydney Page 67
DELETE Semantics
Stop the resource from being accessible
Logical delete, not necessarily physical
Request
DELETE /user/jwebber HTTP/1.1
Host: example.org
Response
200 OK
Content-Type: application/xml
jwebber
This is important for
decoupling implementation
details from resources
The University of Sydney Page 68
HEAD Semantics
HEAD is like GET, except it only retrieves metadata
Request
HEAD /user/jwebber HTTP/1.1
Host: example.org
Response
200 OK
Content-Type: application/xml
Last-Modified: 2007-07-08T15:00:34Z
ETag: aabd653b-65d0-74da-bc63-4bca-ba3ef3f50432
Useful for caching,
performance
The University of Sydney Page 69
OPTIONS Semantics
Asks which methods are supported by a resource
Easy to spot read-only resources for example
Request
OPTIONS /user/jwebber HTTP/1.1
Host: example.org
Response
200 OK
Allowed: GET,HEAD,POST
You can only read and
add to this resource
The University of Sydney Page 70
HTTP Status Codes
The HTTP status codes provide metadata about the state of resources
They are part of what makes the Web a rich platform for building
distributed systems
They cover five broad categories
1xx Metadata
2xx Everythings fine
3xx Redirection
4xx Client did something wrong
5xx Server did a bad thing
There are a handful of these codes that we need to know in more detail
The University of Sydney Page 71
REST Strengths
Simplicity
Uniform interface is immutable (harder to break clients)
HTTP/XML is ubiquitous (goes through firewalls)
Stateless/synchronous interaction
More fault-tolerant
Proven scalability
after all the Web works, caching, clustered server farms for QoS
Perceived ease of adoption (light infrastructure)
just need a browser to get started -no need to buy WS-* middleware
easy to use with any popular rapid-dev languages/frameworks
The University of Sydney Page 72
REST Weaknesses
Mapping REST-style synchronous semantics on top of back end systems creates
design mismatches (when they are based on asynchronous messaging or event
driven interaction)
Cannot yet deliver all enterprise-style -ilities that WS-* can
SOAP services/WS-* provides extensive WS framework and extensions
E.g., Security and transactions are well-supported in WS-*
Challenging to identify and locate resources appropriately in all applications
Semantics/Syntax description very informal (user/human oriented)
Lack of tool support for rapid construction of clients
The University of Sydney Page 73
SOAP or RESTful Services
Service-oriented Architectures can be implemented in different ways
Focus should be on whatever architecture gets the job done and recognize the significant
value of open standards
avoid being religious about any specific architectures or technologies
SOAP and the family of WS-* specifications have their strengths and weaknesses and
will be highly suitable to some applications and positively terrible for others. Likewise
with REST.
The decision of which to use depends entirely on the circumstances of the application.
The University of Sydney Page 74
References
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. 1995. Design
Patterns: Elements of Reusable Object-Oriented Software. Pearson.
Wikipedia, State Design Pattern, https://en.wikipedia.org/wiki/State_pattern
REST in Practice, by Jim Webber, Savas Parastatidis and Ian Robinson; OReilly
2010
Architectural Styles and the Design of Network-based Software Architectures by R.
Fielding (PhD thesis, 2000).
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Enterprise-Scale Software Architecture (COMP5348) slides
Web Application Development (COMP5347) slides
Wikipedia, List of Web Services Specifications.
https://en.wikipedia.org/wiki/List_of_web_service_specifications
https://en.wikipedia.org/wiki/State_pattern
https://en.wikipedia.org/wiki/List_of_web_service_specifications
The University of Sydney Page 75
W11 Tutorial: Practical
Exercises/coding
W11 Lecture: Software
Verification
Design Pattern Assignment
Reviews
There are no reviews yet.