1 / 36

SOA Guiding Principles

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.

delmaw
Download Presentation

SOA Guiding Principles

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 (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 (c) Ian Davis

  3. 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

  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 (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 (c) Ian Davis

  6. N-tier Architectures (c) Ian Davis

  7. Action Domain Responder Stateful Request JavaScript Browser Many scripts • Typical web development style • https://github.com/pmjones/adr PHP SQL HTML (c) Ian Davis

  8. Multi tier Architecture (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 (c) Ian Davis

  10. Source: Wikipedia (c) Ian Davis

  11. Multi Tier • More than three tiers • Routing between Display and Process • Distributed Processing • Distributed Database Layer (c) Ian Davis

  12. 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

  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 (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 (c) Ian Davis

  15. Data Centric Architecture (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

  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

  18. Repository Style (Cont’d) (c) Ian Davis

  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 (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 (c) Ian Davis

  21. 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

  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. (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

  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 (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

  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

  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

  28. DISTRIBUTED REPOSITORY (c) Ian Davis

  29. Scalable Data Architectures • Vertical Scaling • Buy Faster CPU / More memory / Larger Disks • Horizontal Scaling • Buy more cheap servers • Parallelism • Routing (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 (c) Ian Davis

  31. (c) Ian Davis

  32. (c) Ian Davis

  33. Star Schema https://en.wikipedia.org/wiki/Star_schema (c) Ian Davis

  34. Snowflake Schema https://en.wikipedia.org/wiki/Snowflake_schema (c) Ian Davis

  35. RDBMS SQL systems • MySQL (Free) • Oracle • DB2 • SQL Server • Etc. Etc. (c) Ian Davis

  36. 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

More Related