Download presentation
Presentation is loading. Please wait.
1
SOA Guiding Principles
Discovery (OASIS Reference Model) Electronic access to service documentation Standardized Service Contract (WSDL) Ability to establish protocol to a known service Service abstraction Say what a service offers (and no more) Remote procedure call paradigm Wikipedia Spring 2017 (c) Ian Davis
2
SOA Implementation Goals
Stateless (robust and scalable) Service reusability Generalize rather than specialize (usefulness) Loose service coupling (minimize dependency) Composability (simplify reusability) Service autonomy Ability to change / Ability to survive change Wikipedia Spring 2017 (c) Ian Davis
3
Web services A common standard to support SOA Offers
Focus on simplicity and interoperability Offers Find out about a service (WSDL) Find an instance of that service (UDDI) Ask a service to do something (SOAP) Assisting standards (e/g. Security) (WS-*) XML based, with HTTP transport layer HTTP is firewall friendly - ergo dangerous Basically implemented as automated s Spring 2017 (c) Ian Davis
4
REST Versus SOA REST A simple client server interface (Text based)
What the server does is encoded in the message Familiar well understood established standard Transparency w.r.t. client requests Must know URL of end point Circumvents firewalls (requires only HTTP) If you want it you create it No security, reliability, etc. Message paradigm Spring 2017 (c) Ian Davis
5
SOA More flexible Network of interacting components (Procedural)
Access to rich set of WS-* standards and features Reusable tool based architecture Supports distribution/replication of components Offers better security, reliability, interoperability Complex evolving set of standards Layered architecture paradigm Spring 2017 (c) Ian Davis
6
N-tier Architectures Spring 2017 (c) Ian Davis
7
Action Domain Responder
Stateful Request JavaScript Browser Many scripts PHP SQL HTML Typical web development style Spring 2017 (c) Ian Davis
8
Multi tier Architecture
Spring 2017 (c) Ian Davis
9
Three Tier (Display↔Process ↔State)
Display and User interaction E.G. Client Browser Thin (Just Display and front end interaction) Thick (Lots of additional front end computation) Processing E.G. Back End Server Business Logic State or Model E.G. Database Spring 2017 (c) Ian Davis
10
Source: Wikipedia Spring 2017 (c) Ian Davis
11
Multi Tier More than three tiers Routing between Display and Process
Distributed Processing Distributed Database Layer Spring 2017 (c) Ian Davis
12
Layered .v. Multi Tier Layered architecture Multi tier architecture
Architecture based on logical division Multi tier architecture Leverages Client Server Architecture based on physical division Architecture more dependent on infrastructure Assume client has browser Assume server running apache, etc. Spring 2017 (c) Ian Davis
13
Multi-tier advantages
Code is located where most efficiently run Scalability Multiple clients can share one server Multiple servers can share one data base Multi-threading support built in to Browsers, Apache and SQL Leverages existing technology Spring 2017 (c) Ian Davis
14
Multi tier Disadvantages
Communication overhead Hard to perform regression testing etc. Hard to debug No single debugger can watch everything Hard to interpret logs Dependent on remote resources More points of possible failure Spring 2017 (c) Ian Davis
15
Data Centric Architecture
Spring 2017 (c) Ian Davis
16
Blackboard/Repository Style
Suitable for applications in which the central issue is establishing, augmenting, and maintaining a complex central body of global information. Typically the information must be manipulated in a variety of ways. Often long-term persistence is required. (c) Ian Davis Spring 2017
17
Repository Style (Cont’d)
Components: A central “global” data structure representing the correct (or known) state of the system. A collection of independent components that operate on the central data structure. Connectors: Typically procedure calls or direct memory accesses. (c) Ian Davis Spring 2017
18
Repository Style (Cont’d)
(c) Ian Davis Spring 2017
19
Blackboard Architecture
No deterministic solution to problem Global state more as currently known than correct Lots of experts can assist solve the problem Have the experts independently collaborate Like a team working on a blackboard But typically without knowledge of each other Any expert can add to current knowledge Each experts improvement may help others Spring 2017 (c) Ian Davis
20
Mixture of experts Example
One is good at predicting normal load behaviour (But terrible for predicting when peak loads will occur) One is good for predicting high load behaviour (But terrible at predicting more normal loads) Weight predictions based on past accuracy Switch to which ever is currently best predictor An Empirical Investigation of An Adaptive Utilization Prediction Algorithm 23rd Annual International Conference on Computer Science and Software Engineering CASCON 2013 Spring 2017 (c) Ian Davis
21
Repository Style Consistency of global data Database
Policed, controlled through locking etc. Database SQL (Relational database) OMDG (Object oriented database) Database is viewed as a server All requests performed by clients Spring 2017 (c) Ian Davis
22
Repository Style Interaction
ODBC / OLEDB / PhP connectors etc. Triggers Invoke PL/SQL External clients can be notified of changes Implicit invocation SQL3 promises to be computationally complete. Spring 2017 (c) Ian Davis
23
Repository Style Specializations
Data structure in memory Real time Persistent but limited memory Ipod Nano Data structure on disk SQL Ipod Classic Atomic Transactions Concurrent computations and data accesses. (c) Ian Davis Spring 2017
24
Rule Based / Expert System
Repository is a collection of facts (rules) New facts can be added and old facts deleted Can ask questions about these facts Inference engine infers answer from facts Prolog A.I. Programming language Satisfiability solvers Spring 2017 (c) Ian Davis
25
Repository Style Examples
Information Systems Programming Environments Graphical Editors AI Knowledge Bases Ipod Web (HTML data model) Architecture nodes and links between them (c) Ian Davis Spring 2017
26
Repository Style Advantages
Efficient way to store data. Sharing model is available as a schema Centralized management: backup security concurrency control Ability to easily extend the data schema Reliable (no need to test) (c) Ian Davis Spring 2017
27
Repository Style Disadvantages
Must agree on a data model a priori. Partially addressed through views Difficult to distribute data. Partially addressed through distributed DB. Data evolution is expensive. Because much may have to be changed Scalability (read once write everywhere) Somewhat addressed by distributed DB (c) Ian Davis Spring 2017
28
DISTRIBUTED REPOSITORY
Spring 2017 (c) Ian Davis
29
Scalable Data Architectures
Vertical Scaling Buy Faster CPU / More memory / Larger Disks Horizontal Scaling Buy more cheap servers Parallelism Routing Spring 2017 (c) Ian Davis
30
Usage of Data On-line Transaction Processing (OLTP)
Large volumes of INSERT/UPDATE/DELETE Simple SELECT statements (direct recovery) Goal: Storage/Retrieval: Transactions Per Second On-line Analytical Processing (OLAP) Warehoused data (Extract / Transform / Load) (ETL) Very complex operations on the data Goal: Knowledge: Response time per query Spring 2017 (c) Ian Davis
31
Spring 2017 (c) Ian Davis
32
Spring 2017 (c) Ian Davis
33
Star Schema https://en.wikipedia.org/wiki/Star_schema Spring 2017
(c) Ian Davis
34
Snowflake Schema https://en.wikipedia.org/wiki/Snowflake_schema
Spring 2017 (c) Ian Davis
35
RDBMS SQL systems MySQL (Free) Oracle DB2 SQL Server Etc. Etc.
Spring 2017 (c) Ian Davis
36
cdn.oreillystatic.com/en/assets/1/event/100/Big%20Data%20Architectural%20Patterns%20Presentation.pdf Spring 2017 (c) Ian Davis
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.