Your SlideShare is downloading. ×
Service-Oriented Architecture (SOA)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Service-Oriented Architecture (SOA)

375
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
375
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Enterprise Architecture Enterprise Architecture Integration (EAI) Traditionally proprietary silos, vendor lock-in, e.g. CRM Web Services Can support SOA if services are coarse-grained enough Web Services are: SOA plumbing WS is to SOA what HTTP is to Amazon Middleware Can support SOA if message-based and works well in a heterogeneous environment - ESB Client/Server Architecture No dynamic discovery Object-Oriented Programming Too chatty, network communications bloat Objects have state, services are complete-and-forget Distributed Computing Traditionally not scalable & loosely coupled Unwanted intimacy required between entities SOA does use Dist Comp, but that’s not all it is IT-only Need to be driven by business needs SOA cuts across the entire enterprise IT will have a big role to play
  • This is a typical implementation such as is used for Web Services. As such, it is one way in which the day-to-day use of services in an SOA could work.
  • Here, we’re just trying to show that a service comes about when one party has a capability that another needs. So, the dichotomy of a service is provider/consumer.
  • Transcript

    • 1. Service-Oriented Architecture (SOA)
    • 2. Topics Sec. TOPICS 5 5. The Road Ahead 4 4. How Does It Work? 3 3. Benefits 2 2. What is SOA? 1 1. The Setting
    • 3. The Setting
    • 4. What’s the Problem?
      • Increasing Complexity
      • Legacy Applications
      • Stovepipes – Islands of Automation
      • Linkage between Strategic Intent and Information Technology (IT)
      • Lock-In: Platform, Technology, Vendor
      • Cost of IT
      • Time to Market
      • Success!?!?
    • 5. What Do You Want?
      • Extend the value chain to suppliers and customers (citizens)
      • Respond to change quickly and effectively
      • Reduce IT costs
      • Get more bang for the buck from IT investments
      • Get everything to work well together (integration)
    • 6. What is SOA?
    • 7. What Is SOA?
      • SOA is an architectural style whose goal is to achieve loose coupling among interacting services
      • It is a way to organize and use capabilities that may be under the control of different owners.
      • It provides a uniform means to offer, discover, interact with, and use capabilities without having to know all of the underlying technical details.
    • 8. What Distinguishes SOA?
      • Reusability
      • Loose Coupling
      • Discoverability
      • Abstraction
      • Composability
    • 9. SOA is Not…
      • Enterprise Architecture
      • Web Services
      • Middleware
      • Client/Server Architecture
      • Object-Oriented Programming
      • Distributed Computing
      • IT-only
    • 10. SOA is Not Client-Server No Dynamic Discovery – all interactions known in advance
    • 11. SOA is Not DCOM
      • Proprietary and platform dependent
      • Application level not business level
    • 12. SOA is Not Classic Mainframe Environment
      • Platform dependent
      • Tightly-coupled
      Mainframe
      • Operating System
      • User Interface
      • DBMS
      • Communications
      Terminal Terminal Terminal
    • 13. SOA is Not Common Request Broker Architecture (CORBA)
      • Doesn’t address business processes or business process interoperability
      • Broker-based, not message-based
      • Not flexible enough
      • Highly structured data
      • Too complex
    • 14. An Example Implementation of SOA e.g. Web Services
    • 15. Benefits
    • 16. Benefits
      • Reduced risk from standards-based frameworks
      • Reduced development cost
      • Accelerated development
      • Increased responsiveness
      • Leveraged existing IT assets via “exposure” as reusable services
    • 17. Benefits: The Bottom Line
      • The main drivers for SOA-based architectures are to facilitate the manageable growth of large-scale enterprise systems, to facilitate Internet-scale provisioning and use of services and to reduce costs in organization-to-organization cooperation.
      • The concepts used in SOA are not new, but using them to align the business strategies together with IT initiatives is.
    • 18. How Does It Work?
    • 19. Service
      • A service in SOA is like a web site for machines instead of people
      • A service is a composable, universally accessible function with:
        • The capability to perform work for another
        • The specification of the work offered for another
        • The offer to perform work for another
      • Needs and capabilities exist independent of SOA
      • Services are the mechanism whereby needs and capabilities are brought together
    • 20. The Dichotomy of a Service
      • Consumer (traveler) has a Need (transportation)
      • Provider (carrier) has a Capability (flight)
    • 21. Example SOA Network Source: http://www.optaros.com/pdf/wp_AMichelson_SOA_OSS.pdf
    • 22. Functional Regions of an SOA Architecture http://www.optaros.com/pdf/wp_AMichelson_SOA_OSS.pdf
    • 23. The Road Ahead
    • 24. Real World Challenges
      • Education
      • Hype, buzzwords and tools
      • Alignment with business needs
      • High initial cost
      • Adaptation of large silo-based enterprise solutions
      • Security
      • Testability
      • Governance
    • 25. Best Practices
      • Take a top-down approach
      • Start small (one service)
      • Target evolutionary transition, not revolutionary
      • Don’t wait for standards – just do it and focus on interoperability
      • Keep it loosely coupled and “coarsely grained”
      • Build infrastructure only as required to support the current application being developed
    • 26. Standards
      • Organization for the
      • Advancement of
      • Structured
      • Information
      • Standards
      • (http://www.oasis-open.org)
      • 1993
      • Non-profit
      • International
      • > 5000 participants
      • > 600 organizations
      • > 100 countries
      • Reference Model for Service
      • Oriented Architecture 1.0
      • Public Review Draft 2
      • 31 May 2006
      • Identifier: wd-soa-rm-pr2
      • Encourage the continued growth of different and specialized SOA implementations whilst preserving a common layer of understanding about what SOA is

    ×