Soa

1,475 views

Published on

Introduction to SOA

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,475
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
59
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 2003 PSS Global Summit
  • 2003 PSS Global Summit
  • 2003 PSS Global Summit Emphasize that the rationale for the architectural decisions is very important.
  • 2003 PSS Global Summit Software architecture is the collection of the fundamental decisions about a software product/solution designed to meet the project's quality attributes (i.e. requirements). The architecture includes the main components, their main attributes, and their collaboration (i.e. interactions and behavior) to meet the quality attributes. Architecture can and usually should be expressed in several levels of abstraction (depending on the project's size).   If an architecture is to be intentional (rather than accidental), it should be communicated. Architecture is communicated from multiple viewpoints to cater the needs of the different stakeholders. Every system has an architecture, even if it is not formally “spec’ed out”.
  • A Solution to world hunger Not a solution for everything Just another tool in the toolset A specific Technology Most notably SOA  Web Services Will Not make all code reusable A New name for EAI Though well established contracts can help that too A New way to do RPC 2003 PSS Global Summit
  • 2003 PSS Global Summit
  • 2003 PSS Global Summit
  • Business Alignment Can’t stress that enough Reduced assumptions (loose coupling) Builds on ideas from component software, distributed objects, and MOM BPM … All the stuff enterprise architects do 2003 PSS Global Summit
  • A service is a program you interact with via message exchanges Services are built to last Encompass a business perspective Stability and robustness are critical A system is a set of deployed services cooperating in a given task Systems are built to change Adapt to new services after deployment 2003 PSS Global Summit
  • Each Service interaction is a boundary crossing Don’t cross it with transactions / exceptions etc. Crossing service boundaries may have costs Service Orientation helps makes interaction formal, intentional, and explicit Service boundary is a trust boundary ! Respect my Boundaries (Adopted from Alex Weinert, Clemens Vasters) 2003 PSS Global Summit
  • Autonomous services can mean many things. One explanation I’ve heard was the autonomous means that the teams working on different teams can be autonomous. While, this is a nice “feature” to have, a much more valuable (as in “business value”) definition is that the services are as self sufficient as possible. For example a imagine a journal subscription agency which needs to create a proposal for a client. The proposal service needs among other things, to produce a “pro forma” invoice in order to do that it must get the customer’s discount rate and the customer’s discount rate as well as the publisher’s discount rates (to check if the proposal is profitable) see the flow in figure 2.X below . If the proposal service is not autonomous it has to wait for two other services and while the customer service is local the publisher’s discount might be a remote one (on the publisher’s system) – what happens to our proposal service if the publisher’s system is not on-line? 2003 PSS Global Summit
  • Service compatibility is determined based on policy Object-oriented designs often confuse structural compatibility with semantic compatibility. Service-orientation deals with these two axes separately. Structural compatibility is based on contract and schema and can be validated (if not enforced) by machine-based techniques (such as packet-sniffing, validating firewalls). Semantic compatibility is based on explicit statements of capabilities and requirements in the form of policy.   Every service advertises its capabilities and requirements in the form of a machine-readable policy expression. Policy expressions indicate which conditions and guarantees (called assertions) must hold true to enable the normal operation of the service. Policy assertions are identified by a stable and globally unique name whose meaning is consistent in time and space no matter which service the assertion is applied to. Policy assertions may also have parameters that qualify the exact interpretation of the assertion. Individual policy assertions are opaque to the system at large, which enables implementations to apply simple propositional logic to determine service compatibility. A Policy is a set of assertions made about Security messages behavior level of service limited by the actual service capabilities Policy-sets are attached, embedded or otherwise associated with contracts Policy specifies a run-time dynamic, negotiable configuration information for a contract implementation. 2003 PSS Global Summit
  • 2003 PSS Global Summit Took Clemens example – but Reversed contract direction – The is “owned” by the service provider not the consumer
  • address, a URI, a specific place where the service can be found. A specific contract can be exposed at a specific endpoint. 2003 PSS Global Summit
  • Services Revolve Around Messages Services Are “Black Boxes” Messages go in and out The Rest Is an Implementation Detail! 2003 PSS Global Summit
  • Between Services is Special Messages Are Sent and Float Around Between Special Care Is Needed to Understand Them Can Be Confusion About Interpreting Them Many Kinds of Message transports Email, IP, TCP/IP, HTTP, Web-service, MSMQ, MQ-Series, and more Many Kinds of Message structures XML, Binary, whatever May be OK to Have Some Message Loss If messages are idempotent Other option “Reliable Messaging” 2003 PSS Global Summit
  • 2003 PSS Global Summit
  • One Way Incoming Outgoing Broadcast Publish (as in publish/subscribe) To single recipient Duplex Two one-ways Request/Reply R equest/Reaction 2003 PSS Global Summit
  • Messages & Formats Message Exchange Patterns Where is a service located (Address) Protocol & content format (Binding) 2003 PSS Global Summit
  • Service Data is private Keep DB private Keep transactions private Keep exceptions private Don’t share classes or other internal data structures Don’t share too much – or you’ll lose autonomy (or tempt others to lose it) 2003 PSS Global Summit
  • Services interactions are message driven Services should be Loosely coupled Edges should provide location transparency Business logic and edge are separate layers Scale inside the service You can use workflows for long-running interactions again - inside the service 2003 PSS Global Summit
  • Soa

    1. 1. Service Oriented Architecture An Introduction Arnon Rotem-Gal-Oz Biometrics Line Development Manager
    2. 2. What is Software Architecture
    3. 3. What is Architecture Formal Definition <ul><li>IEEE 1471-2000 </li></ul><ul><ul><li>Software architecture is the fundamental organization of a system, embodied in its components , their relationships to each other and the environment, and the principles governing its design and evolution </li></ul></ul>IEEE 1471-2000
    4. 4. <ul><li>collection of the fundamental decisions about a software product/solution designed to meet the project‘s quality attributes </li></ul><ul><li>Includes the main components, their main attributes, and their collaboration </li></ul><ul><li>expressed in several levels of abstraction (depending on the project's size). </li></ul><ul><li>  </li></ul><ul><li>Architecture is communicated from multiple viewpoints </li></ul>What is Software Architecture
    5. 5. Architecture is Early <ul><li>Architecture represents the set of earliest design decisions </li></ul><ul><ul><li>Hardest to change </li></ul></ul><ul><ul><li>Most critical to get right </li></ul></ul><ul><li>Architecture is the first design artifact where a system’s quality attributes are addressed </li></ul>
    6. 6. Why Architecture? <ul><li>Architecture serves as the blueprint for the system but also the project: </li></ul><ul><ul><li>Team structure </li></ul></ul><ul><ul><li>Documentation organization </li></ul></ul><ul><ul><li>Work breakdown structure </li></ul></ul><ul><ul><li>Scheduling, planning, budgeting </li></ul></ul><ul><ul><li>Unit testing, integration </li></ul></ul><ul><li>Architecture establishes the communication and coordination mechanisms among components </li></ul>
    7. 7. Quality Attributes
    8. 8. How Architecture Architecture Quality Attributes Technology Patterns & Anti-patterns Principles Community experience Stakeholders Architect Constraints people A “deliverable” Produce Key Is an input
    9. 9. What is a Service (1) <ul><li>A facility supplying some public demand </li></ul><ul><li>the work performed by one that serves HELP , USE , BENEFIT </li></ul>Merriam-Webster HMM..
    10. 10. What is a Service (2) <ul><li>In economics and marketing, a service is the non-material equivalent of a good. Service provision has been defined as an economic activity that does not result in ownership, and this is what differentiates it from providing physical goods. </li></ul><ul><li>It is claimed to be a process that creates benefits by facilitating either a change in customers, a change in their physical possessions, or a change in their intangible assets. </li></ul>en.wikipedia.org/wiki/Service
    11. 11. What is a service (3) <ul><li>A Windows Service? </li></ul><ul><ul><li>RPC Locator, EventLog, DHCP Client, </li></ul></ul><ul><li>Software Service? </li></ul><ul><ul><li>Distribution Service, Alert Service </li></ul></ul><ul><ul><li>Security Service, Log Service </li></ul></ul><ul><li>Business Service? </li></ul><ul><ul><li>Common Operational Picture, Navigation </li></ul></ul><ul><ul><li>Accounts Receivable, Customers </li></ul></ul>
    12. 12. SOA isn’t a solution to world hunger <ul><li>Nor is it: </li></ul><ul><li>A specific Technology </li></ul><ul><li>The Ultimate answer to reuse </li></ul><ul><li>A New name for EAI </li></ul><ul><li>A New way to do RPC </li></ul>
    13. 13. Big SOA Analyze the business ASB BLT HDL AFT TGI FRY DRW SWG QYD DLY BST WIU ASB ZIS XOI CUI RMO DLY XPS KYF KFC WHR JIA GEX FQA VUH HCO WKD ECP SKD MFP WCP DKE AJT
    14. 14. Big SOA Identify Business Areas ASB BLT HDL AFT TGI FRY DRW SWG QYD DLY BST WIU ASB ZIS XOI CUI RMO DLY XPS KYF KFC WHR JIA GEX FQA VUH HCO WKD ECP SKD MFP WCP DKE AJT COP Navigation Protectors Alerts
    15. 15. Big SOA Map to software &quot;Network&quot; COP Nav. Alerts Prot.
    16. 16. Little SOA <ul><li>Architectural Style </li></ul><ul><li>For building distributed systems </li></ul><ul><li>Loosely coupled components </li></ul><ul><li>Our focus from here onward… </li></ul>
    17. 17. Service describes End Point Exposes Messages Sends/Receives Contracts Binds to Service Consumer implements Policy governed by Sends/Receives Adheres to Component Relation Key Understands Serves
    18. 18. Services and Systems <ul><li>A service is a program you interact with via message exchanges </li></ul><ul><li>A system is a set of deployed services cooperating in a given task </li></ul>
    19. 19. A Service edge is a natural boundary Warning: Remoting and other RPCs trick us into thinking that there is no substantial difference between a local and a remote object. In fact, they hide the presence of the network.
    20. 21. Services are Autonomous
    21. 22. X
    22. 24. The fact that I can, doesn’t mean I will. Policies
    23. 25. Policy Illustrated Seller Service Runtime contract <ul><li>Runtime Contract </li></ul><ul><ul><li>1. Use X.509 Cert for AuthN </li></ul></ul><ul><ul><li>2. Use UTF-8, SOAP 1.2 </li></ul></ul><ul><ul><li>… </li></ul></ul>Policy 1. Supports X.509 Cert or Kerberos ST for AuthN 2. Supports UTF-8, UTF-16, SOAP 1.2, 1.1 … Adopted from Clemens Vasters Design time Contract 1. You’ll send a PO 2. I’ll send a confirmation … Organization A Organization B Policy Policy Buyer Service Local Service Local Service
    24. 26. Endpoint
    25. 27. It’s all about the Message, baby!
    26. 28. Messages travel in no man’s land!
    27. 29. Is he Idempotent? Messages Get Retransmitted Messages Arrive More than once
    28. 30. Idempotence <ul><li>Idempotent Means It’s OK to Arrive Multiple Times </li></ul><ul><ul><li>As Long as the Request Is Processed at Least Once, the Correct Stuff Occurs </li></ul></ul><ul><li>In Today’s Internet, You Must Design Your Requests to Be Idempotent </li></ul>Not Idempotent Baking a Cake Starting from Ingredients Naturally Idempotent Sweeping the Floor Naturally Idempotent Read Record “X” Idempotent If Haven’t Yet Done Withdrawal #XYZ for $1 Billion, Then Withdraw $1 Billion and Label as #XYZ Not Idempotent Withdrawing $1 Billion Idempotent Baking a Cake Starting from the Shopping List (If Money Doesn’t Matter) Pat Helland
    29. 31. Message Exchange Patterns
    30. 32. Request/Reply Request/Reaction VS
    31. 33. Decoupled Invocation Pattern
    32. 34. Service Contract
    33. 35. Keep Data and state private
    34. 36. <ul><li>Big SOA is about business alignment </li></ul><ul><li>Little SOA is an Architectural Style </li></ul><ul><ul><li>Autonomous Coarse Grained Components </li></ul></ul><ul><ul><li>Message based Interactions </li></ul></ul><ul><ul><li>Run-Time configuration </li></ul></ul>
    35. 37. What’s next <ul><li>SOA Structural Patterns </li></ul><ul><li>SOA Interaction Patterns </li></ul><ul><li>UI Interaction Patterns </li></ul><ul><li>Service Composition Patterns </li></ul><ul><li>Contract Anti-patterns </li></ul><ul><li>Service Anti-patterns </li></ul><ul><li>SOA Performance Anti-Patterns </li></ul>

    ×