Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Write this down: An architecture is a framework that guides the significant decisions involved in creating or enhancing something that matters. Matters = important enough that you want to be thoughtful and controlled in your decision-making. Means that success or fulfillment depends on how it turns out. Generally, but not always, that means something that is (a) complex, (b) expensive and (c) hard to undo.
  • Many of us understand what is meant by a Craftsman house, a Tudor house, a Victorian house, or a Federal house. These houses have many things in common: houses built according to any of these styles can be functional, comfortable. None is better than any other. We use the stylistic labels as a way to convey certain desirable characteristics that we want to achieve from designs.
  • Ask about styles of application architecture, as a further illustration
  • Point out that this is an evolution…towards what? (Agility)
  • Architecture should tell us: How do we describe/define exchanges (requirements)? How do we format the information? How is information transported (securely, reliably)? How do systems connect? What infrastructure do we share? What does it do? What technologies? How do we find exchanges? Who does/owns/funds what?
  • Abstractness A service’s models and name should reflect what the service does or what it accomplishes and should not describe how the service works or how it is implemented. Autonomy There should be one and only one service that produces a given real-world effect. Once a service is available to provide access to a capability, consumers should not access that capability except through the service. Reusability A service should not preclude usage by consumers or in contexts not explicitly prohibited by the service’s stated policy or contract. Loose Coupling A service should have minimal dependencies on other services, the execution context, and the business organization responsible for providing it. Separable real-world effects should be achieved through use of separate services. Statelessness All information necessary for a service to perform an action in its action model should be provided by the consumer during interaction, or obtained by the service implementation during performance of the action. A service should not rely upon information retained from a previous interaction with a consumer.
  • At the end of this slide, make a couple of key points: We have not once yet talked about a specific vendor product or even class of products We have not yet mentioned web services, SOAP, etc.

    1. 1. What is SOA? NAJIS Conference Santa Fe, NM October 17, 2007 Mark Perbix Justice Information Systems Specialist SEARCH
    2. 2. Learning Objectives <ul><li>What is architecture? </li></ul><ul><ul><li>Why do we need it? </li></ul></ul><ul><li>What does “SOA” mean? </li></ul><ul><li>What does SOA look like? </li></ul><ul><li>How do we implement SOA? </li></ul>
    3. 3. What is Architecture? An architecture is a framework that guides the significant decisions involved in creating or enhancing something that matters.
    4. 4. Style of Design
    5. 5. Styles As Shorthand <ul><li>Architectures tend to be complex </li></ul><ul><li>Laypeople (buyers) and architects (builders/designers) need efficient, effective communication </li></ul><ul><li>A style is a label for a set of decision outcomes </li></ul><ul><li>A style is like an “off-the-shelf” architecture </li></ul>
    6. 6. Styles of Information Sharing Architecture Shared User Interface Shared Database File Transfer/Remote DB Access
    7. 7. What is SOA? <ul><li>SOA is a style of information sharing architecture </li></ul><ul><li>Distinguishing Features: </li></ul><ul><ul><li>Keeps implementations separate (services) </li></ul></ul><ul><ul><li>Autonomy: standardize on the “what”, specialize on the “how” </li></ul></ul><ul><ul><li>Formal, precise, but minimalist standards </li></ul></ul><ul><ul><li>Open (non-proprietary) standards </li></ul></ul><ul><ul><li>Share common services </li></ul></ul><ul><ul><li>Reuse components </li></ul></ul><ul><ul><li>The model is the software </li></ul></ul><ul><ul><li>Separate integration logic from internal system logic </li></ul></ul>
    8. 8. SOA Principles/Goals <ul><li>Abstractness </li></ul><ul><li>Autonomy </li></ul><ul><li>Reusability </li></ul><ul><li>Loose Coupling </li></ul><ul><li>Statelessness </li></ul>
    9. 9. SOA Style
    10. 10. SOA is not just technology <ul><li>Enterprise Service Bus </li></ul><ul><li>Message Bus </li></ul><ul><li>Message Hub </li></ul><ul><li>Data Hub </li></ul><ul><li>Broker </li></ul><ul><li>Switch </li></ul><ul><li>Technology is an important component of an SOA approach but do not define SOA </li></ul>
    11. 11. SOA is a complete package <ul><li>More than just technology… </li></ul><ul><ul><li>Policies, Standards, Guidelines… </li></ul></ul><ul><ul><li>Agreements, Management Strategies… </li></ul></ul><ul><ul><li>Infrastructure Requirements… </li></ul></ul><ul><ul><li>…that produce the distinguishing characteristics of the SOA style </li></ul></ul>
    12. 12. Incremental Adoption of SOA Agility XML Industry Standards Controlled vocab Standard messages (IEPDs) SOAP WS-* Location Independence (registry) Repositories Separation of Business logic (intermediaries) Provisioning Models (shared services) Event-driven architecture Shared Message Transport
    13. 13. Summary <ul><li>Architecture is a framework to guide decisions </li></ul><ul><li>Styles provide convenient labels for certain desirable outcomes </li></ul><ul><li>Information sharing architecture guides decisions about integrating systems </li></ul><ul><li>SOA is a style of information sharing architecture </li></ul><ul><li>SOA is a set of principles, policies, standards, guidelines, agreements, and requirements for shared infrastructure </li></ul>