360 likes | 411 Views
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.
E N D
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 (c) Ian Davis
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 (c) Ian Davis
Web services • A common standard to support SOA • 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 emails (c) Ian Davis
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 (c) Ian Davis
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 (c) Ian Davis
N-tier Architectures (c) Ian Davis
Action Domain Responder Stateful Request JavaScript Browser Many scripts • Typical web development style • https://github.com/pmjones/adr PHP SQL HTML (c) Ian Davis
Multi tier Architecture (c) Ian Davis
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 (c) Ian Davis
Source: Wikipedia (c) Ian Davis
Multi Tier • More than three tiers • Routing between Display and Process • Distributed Processing • Distributed Database Layer (c) Ian Davis
Layered .v. Multi Tier • Layered 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. (c) Ian Davis
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 (c) Ian Davis
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 (c) Ian Davis
Data Centric Architecture (c) Ian Davis
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
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
Repository Style (Cont’d) (c) Ian Davis
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 (c) Ian Davis
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 (c) Ian Davis
Repository Style • Consistency of global data • Policed, controlled through locking etc. • Database • SQL (Relational database) • OMDG (Object oriented database) • Database is viewed as a server • All requests performed by clients (c) Ian Davis
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. (c) Ian Davis
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
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 (c) Ian Davis
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
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
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
DISTRIBUTED REPOSITORY (c) Ian Davis
Scalable Data Architectures • Vertical Scaling • Buy Faster CPU / More memory / Larger Disks • Horizontal Scaling • Buy more cheap servers • Parallelism • Routing (c) Ian Davis
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 (c) Ian Davis
Star Schema https://en.wikipedia.org/wiki/Star_schema (c) Ian Davis
Snowflake Schema https://en.wikipedia.org/wiki/Snowflake_schema (c) Ian Davis
RDBMS SQL systems • MySQL (Free) • Oracle • DB2 • SQL Server • Etc. Etc. (c) Ian Davis
www.youtube.com/watch?v=-N9i-YXoQBE&list=PL-tg-8BR7u1f0uH-b4m5gr144aP0ketEkwww.youtube.com/watch?v=-N9i-YXoQBE&list=PL-tg-8BR7u1f0uH-b4m5gr144aP0ketEk cdn.oreillystatic.com/en/assets/1/event/100/Big%20Data%20Architectural%20Patterns%20Presentation.pdf (c) Ian Davis