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