Your SlideShare is downloading. ×
  • Like
Download Presentation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Download Presentation

  • 319 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
319
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
9
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
  • Module Goals: At the end of this module, learners will be able to describe the challenges associated with implementing SOA and discuss potential pathways towards solutions for these issues. This module employs a diagnostic assessment to discover the audience’s pre-existing familiarity with the material. The instructor can use the outcome of the initial evaluation to set the pace for the module. The diagnostic assessment also helps direct learners to questions they should ask towards mastery of the material. All slide timing numbers are rough approximations to be used as guidelines. The actual time spent per slide will depend on the level of interaction with the students. Questions will obviously increase the time spent on a slide. There is an exercise at the end of this module that ties this module to real world application on the job. The total timing of the exercise is approximately 30 minutes, depending on class size. Minimum Prerequisites: Module 1: Introduction to SOA, Module 2: Understanding SOA Basics and Module 3: The SOA Roadmap. Classroom setup: None required Intended Audience: This module is intended for people who will be responsible for implementing SOA including Enterprise Architects, Business Analysts, IT developers and other stakeholders. Expected Duration for Course : 1.5 to 2 hours. Module Flow: This module is comprised of a logical presentation of concepts that cumulatively accomplish the module goal of being able to describe the challenges associated with implementing SOA and discuss potential pathways towards solutions for these issues. The module has an overall introduction listing what the learners will accomplish in the module. Each concept includes an introduction, a discussion of the concept and a summary with review questions to check comprehension. Finally, there is an overall review of what was accomplished in the module. This module employs a diagnostic assessment to discover the audience’s pre-existing familiarity with the material. The instructor can use the outcome of the initial evaluation to set the pace for the module. The diagnostic assessment also helps direct learners to questions they should ask towards mastery of the material. The total time to complete the main concepts in this module should be approximately 1 hour. Each concept will take no more than 20 minutes: approximately 10 minutes of introduction and discussion followed by approximately 10 minutes of Q&A and review. Each slide has an approximate time guideline listed in the notes section. Classroom setup: None required There is an exercise at the end of this module that ties this module to real world application on the job. The total timing of the exercise is approximately 30 minutes, depending on class size. Key Concepts: Use this starting slide to introduce yourself and discuss logistics. Presentation tip: Set up a safe environment by asking students what the policy should be surrounding information exchange. Typically, the common agreement that “what is said in the room stays in the room” helps foster learning by allowing students to tie the concepts to real-world situations at their own companies. Questions to Address: Will the handouts be available for download?
  • Slide timing: 20 minutes Instructor notes: This is the central slide of the presentation. The remainder of the slides expand on each component of this map. You should refer back to this slide during the rest of the presentation for a high level view of relationships. Point out to the students that as you progress through each milestone, they should be thinking about how each applies to their own corporate environments. Also advise the students that once the map is built out, they will have the opportunity to build it out themselves in an exercise, to insure that they understand the key aspects/milestones of each line. Note: since there is so much data on this slide, it will not be readable as a full screen presentation. You should have a poster handy, and be able to zoom a separate hi-resolution file (provided with this module) to make each section readable as you talk about it. Introduce the 4 lines and each major facet of each line. You should keep it at a high level pointing out the relationships as you will cover details in subsequent slides. Keep mind as you take learners through this slide that when you move to the next slide, learners should be able to demonstrate a high level grasp of: The meaning of the 4 major lines (meaning is more important than memorization): the top orange line is a representation of the implementation phases: Point-to-point integration Loosely coupled services Reliable, discoverable services Composable, reusable services Enterprise SOA. the second-from-the-top blue line represents the implementation timeline, including the following major milestones: Heterogeneous systems with proprietary interfaces (the starting point, not a milestone) Wrap legacy systems in service interfaces Secure service interfaces Create a governance framework Manage services Contract-first development Implement the SOA metamodel Service-oriented process Semantic Integration Dynamic service discovery Service-oriented enterprise the next down representing the integration style: Static binding to static services Dynamic binding to static services Dynamic binding to dynamic services the bottom blue line representing the key ROI of that phase: Reduce cost of application maintenance and point-to-point integration Increase efficiency through service reuse Increase visibility and control Improve business agility While what they see looks rather linear, it is in reality iterative, as will be discussed through the module. This is represented by the wavy line. While this ZapThink SOA roadmap is designed to minimize risk, there could be various starting points and some variance in the order of the milestones.
  • Slide timing: 2-4 minutes Instructor notes: This is an introductory slide beginning the discussion surrounding XML-related issues. A key point to emphasize on this slide is that SOA is enabled by XML – increasing quantities of XML on the net, which causes a variety of problems including those listed. The next slides go into more detail around XML issues. Key Concepts: XML-based Services in an SOA will increasingly pinch existing network infrastructure causing a significant performance and reliability problem. Understand why SOA leverages metadata, which by nature is more verbose and inefficient than point-to-point binary traffic A key point to emphasize on this slide is that SOA is enabled by XML – increasing quantities of XML on the net, which causes a variety of problems including those listed. The next slides go into more detail around XML issues. Questions to address : Why does metadata introduce inefficiencies? Why is XML text-based? Does making XML binary-based help solve any of the problems?
  • Slide timing: 3-5 minutes Instructor notes: This is an introductory/transition slide into security. Go through each stack item, pointing out the differences between Traditional Distributed Computing and Service-Oriented Computing. Presentation suggestion: ask the students where they are on the spectrum between these two contexts. Get them involved in the conversation around security up front to increase retention of this section. If they are unsure, you may want to spend a few extra minutes going through each box talking through the clarifying points under each header (top part of each box). Review question: what is it about SOA that brings security front and center as an issue to address? The answer you are looking for is human-readable XML. Key Concepts: In this set of slides, we will cover several key requirements for building an SOA infrastructure. The first of these is Security. This is an introductory/transition slide into security. Go through each stack item, pointing out the differences between Traditional Distributed Computing and Service-Oriented Computing at each level: network-packet vs application layer, closed vs open systems, fragmented control vs managed security, etc. SOA changes the way we have to deal with Security. In particular; Perimeter-based security doesn’t matter when you are inspecting traffic on a per-message basis Security based on closed system interfaces is not appropriate for loosely-coupled, composite Services that span a wide range of systems and applications It doesn’t make sense to isolate each system for the purposes of security administration. It makes more sense to establish policies and contracts to apply to Services no matter where they are in the network. Presentation suggestion: Ask the students where they are on the spectrum between these two contexts. Get them involved in the conversation around security up front to increase retention of this section. If they are unsure, you may want to spend a few extra minutes going through each box talking through the clarifying points under each header (top part of each box). Questions to address : Review question: what is it about SOA that brings security front and center as an issue to address? The answer you are looking for is human-readable XML. Do you understand how SOA changes the fundamental dynamic of network-based security?
  • Slide timing: 2 minutes Instructor notes: Introducing the concept of management for SOA. Key Concepts: This slide shifts our discussion from concerns around security infrastructure to issues of Service management and reliability. Maintaining the Services abstraction via loose coupling is what’s required of successful SOA implementations. Management of the network becomes critical in this loosely coupled environment. Walk through the 3 different aspects of management: System management: This refers to identifying root causes of technical problems and solving them Metadata management: This refers to storing, managing, and enabling the use of various metadata Business Service management: This refers to managing business Key Performance Indicators (KPIs) in the context of SOA Questions to address : Which aspects of management are you doing now? How are each of these applicable to your SOA implementation? What new requirements on each of these three aspects of management does SOA introduce?
  • Slide timing: 2 minutes Instructor notes: Refer to the ZapThink SOA Roadmap, where management comes early in the roadmap. The reason is that any Services that provide real business value should be managed, even if there is a small number of such Services. Key Concepts: Go through each bullet, emphasizing the timing – you need management BEFORE any significant (as in: mission critical) services are offered, as services without management lead to the larger problem of reigning in “rogue services”. Lack of management leads to problems in every area – security, performance, availability, etc. Referring to the prerequisite ZapThink SOA Roadmap, management comes early in the roadmap. The reason is that any Services that provide real business value should be managed, even if there are a small number of such Services. Questions to address : Are you thinking of (or currently) leveraging your existing Systems Management vendor / product for Services management? If so, do you see this working now and in the future?
  • Slide timing: 2-3 minutes Instructor notes: Service mediation overlaps SO management – some products do both. Mediation is also critical to loose coupling, as well as to the scalability of the overall implementation. Distributed intermediaries are more scalable than a centralized approach, but also require greater management. Key Concepts: This slide shifts the discussion to the third requirement: service mediation. Mediation is described in the bullets – transport protocol mediation, message protocol mediation, transformations and security domains. Point out that Service mediation overlaps SO management – some products do both. Mediation is also critical to loose coupling, as well as to the scalability of the overall implementation. Distributed intermediaries are more scalable than a centralized approach, but also require greater management. Questions to address : How are the existing requirements of mediation handled today? Do you see a software or a hardware role for mediation?
  • Slide timing: 3-4 minutes Instructor’s notes: The term “ESB” is a loaded term, since so many vendors have built their marketing messages on the term. It’s important to be skeptical about all vendor ESB claims. It’s much more important to understand what capabilities you need, and find products that offer those capabilities, than to buy and ESB because you think you need an ESB. Key Concepts: The term “ESB” is a loaded term, since so many vendors have built their marketing messages on the term. It’s important to be skeptical about all vendor ESB claims. Different vendors are inconsistent in their definition and use of ESB. It’s much more important to understand what capabilities you need, and find products that offer those capabilities, than to buy and ESB because you think you need an ESB. Questions to address : What is YOUR definition of an ESB? Is an ESB a product or a pattern / style of infrastructure? If it’s a product, what are the most important features that you require from an ESB, and how are they different from what you already have? What do you see as the most critical aspects of Service mediation?
  • Pull together in one integrated, tested offering: “Older” standards Newer SOA standards and innovation Multiple open source technologies Enterprise-class service and support

Transcript

  • 1. Open & Closed Source Software for SOA Infrastructure Jason Bloomberg Senior Analyst ZapThink, LLC
  • 2. The Three Core SOA Infrastructure Challenges
    • Security
    Management Governance
  • 3. The ZapThink SOA Roadmap: Infrastructure Focus
  • 4. Juggling SOA Infrastructure
    • Successful SOA requires several infrastructure elements
      • Challenges:
      • Priorities?
      • Budgets?
      • Identifying needs?
    • Iterative architectural approach should drive infrastructure decision
    Security Integration Process Management Governance
  • 5. The SOA Performance Issue
    • SOA requires more metadata than ever…
      • Web Services-based SOA is mostly XML-based
      • XML is text heavy and verbose
      • More metadata… more XML… more headaches
    • The XML Processing challenge
      • Per-message parsing, processing
      • Security steps
      • Validity steps
      • Mapping XML to memory models
      • That darn text format!
    • Security, Reliability, Process, and Transaction now on a per-message basis
    • High volumes of messages and very large messages two separate problems
  • 6. First Roadblock: Security
  • 7. The “20 doors” problem
    • Any Web Services/ SOA security approach must be a part of a comprehensive enterprise security initiative
    If your company has 20 doors, and you lock 19, are you 95% secure?
  • 8. 21 st Century Network Security
    • The Old Days:
      • Internal = Trusted
      • External = Untrusted
    • Today:
      • Internal = Untrusted
      • External = Hostile!
    You MUST address security issues throughout the network
  • 9. SOA Management: Many Facets
    • System management – identifying root causes of technical problems, mitigating or solving them
    • Metadata management – storing, managing, and enabling the use of various metadata
    • Business Service management – managing business Key Performance Indicators (KPIs) in the context of SOA
  • 10. The Problem with SOA Management…
    • Managing Service interfaces & dependencies
    • Application management
    • Systems management
    • Network management
    • Root cause analysis
    • Etc…
  • 11. The First Rule of SOA Management
    • You need management when you offer your first “mission critical” Service
    • Even one Service requires management
    • Don’t wait!
  • 12. Metadata Management & SOA
    • Metadata at the core of any SOA implementation
      • Contracts, policies, SOBA configurations, schemas…
    • SOA Governance depends upon metadata as well
    • “Registry/Repository” at the center of the SOA metadata management puzzle
  • 13. Complexities of SOA Governance Marketplace Registry/ Repository SOA Quality Policy Management Design Time SOA Governance Service Lifecycle Management Runtime SOA Governance
  • 14. Introducing Service Mediation
    • Translate between transport protocols (e.g., MQ to HTTP)
    • Translate between message protocols (e.g., SOAP to “Plain old XML”)
    • Handle transformations on the fly
    • Negotiate between different security domains (e.g., PKI to Kerberos using WS-Security)
  • 15. Do You need an ESB for Service Mediation?
    • Enterprise Service Bus (ESB) term not consistently used across products
    • Many ESB products do provide Service mediation
    • Many ESB products also provide message transport or proprietary integration infrastructure, which you may not need
    • Some products provide Service mediation without being an ESB
  • 16. The SOA Integration Spectrum
    • Peer-to-Peer Integration
    • Standards-based Intermediaries
    • Standards-based ESBs
    • ESBs with proprietary messaging
    • EAI suites with Service support
    • Proprietary Integration Middleware
    SOA Software Cape Clear Sonic ESB TIBCO Sun SeeBeyond BEA Aqualogic Service Bus IBM WebSphere ESB SAP NetWeaver webMethods IONA
  • 17. Closed Source vs. Open Source
    • Which would you rather buy?
    OR
  • 18. The Rise of the Integrated SOA Stack
    • “Open Source Vendors” who assemble, integrate, and optimize set of tools
    • Business models are combination of:
      • Support and consulting
      • Upsell to commercial product
      • Addition of value-add commercial tools
    • All leverage Java
    • Examples: WSO2, JBoss, LogicBlaze
    • IONA: Different approach
  • 19. Pros & Cons of Open vs. Closed Source
    • PROS
      • Lower initial cost
      • Lower TCO (maybe)
      • Increased innovation
    • CONS
      • Java-centric
      • Requires larger technical team (maybe)
      • Challenges coordinating/ integrating range of tools
    • PROS
      • “ One throat to choke”
      • Leverage strengths of vendor
      • More likely to be “turn key”
      • Easier to leverage platforms other than Java
    • CONS
      • Higher initial cost
      • Comes with vendor baggage
    Open Source Closed Source
  • 20. Thank You! ZapThink is an industry advisory & analysis firm focused exclusively on Service-Oriented Architecture. Jason Bloomberg [email_address] Read our new book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business.
  • 21. Open & Closed Source Software for SOA
  • 22. Agenda
    • SOA Heritage
    • Next Generation SOA
    • Complementary Open/Closed Source
  • 23. Making Software Work Together
    • 80% of Global Telecom
    • 70% of Financial Services in Global 100
    • Blue Chip Partners
    • EMEA HQ in Dublin, Ireland
    • US HQ in Massachusetts
    • APAC HQ in Tokyo, Japan
    Worldwide presence
    • Founded in 1991
    • Publicly traded since 1997
    • Strong balance sheet
    NASDAQ:IONA Solid business with a history of profitable growth
    • Deliver high performance integration software for mission critical applications
    • Make heterogeneity an asset, not a liability
    • Deliver on the value proposition of standards
    The IONA Approach Customers include world’s largest firms
  • 24. IONA: SOA Heritage
    • 1500 services in production
    • 100,000+ users
    • 1B txns/year, 5M/day
    • 73% cost reduction for systems development and integration (compared to other approaches)
    • Reuse of 70% of services
    • Secure / Reliable
    • Built with IONA
    +
  • 25. IONA Strategy
    • Empowering customers to
        • Generate Greater ROI
        • Streamline and Modernize IT environments
        • Reduce fixed cost of IT infrastructure
    • By providing Distributed SOA Infrastructure
        • IONA developed: Artix, Orbix
        • Community developed: Celtix Enterprise
        • All with enterprise-class services, support
  • 26. IONA’s Open Source Celtix Product Line
    • Expanding leadership in distributed SOA infrastructure with open source
    • Celtix Enterprise
        • Open Source ESB
        • Basis for distributed SOA
    • Celtix Advanced Messaging
        • Open Source Messaging
        • Based on code from Apache Incubator Qpid (AMQP)
    • Celtix Advanced Service Engine
        • Open Source Services Framework
        • Based on code from Apache Incubator CXF
    • Enterprise-class Services and Support
  • 27. Celtix Enterprise Components
    • Celtix Advanced Service Engine
    • Messaging Infrastructure
        • Celtix Advanced Messaging
        • ActiveMQ JMS
        • Routing
    • Flexible Deployment
        • Tomcat
        • JBI container
        • Spring-based Container
        • Supports J2EE
    • Eclipse tooling from the SOA Tools Platform (STP) project
    Routing Java, Javascript/E4X Eclipse STP, code generators, JMX Enabled Celtix Advanced Service Engine Tomcat, J2EE, JBI, Spring HTTP, JMS, AMQP
  • 28. A-la-carte Offerings
    • Celtix Advanced Messaging
        • Based on Apache Qpid, AMQP reference implementation
        • Supports fire-and-forget, publish-subscribe, message queuing
        • AMQP is an open on-the-wire protocol
    • Celtix Advanced Service Engine
        • Based on Apache CXF
        • JAX-WS 2.0 implementation
        • Supports Java and Javascript/E4X
        • SOAP or XML over HTTP, JMS, AMQP
    Celtix Advanced Messaging Routing Java, Javascript/E4X Eclipse STP, code generators, JMX Enabled Celtix Advanced Service Engine Tomcat, J2EE, JBI, Spring
  • 29. Hub-based Architecture – “Before”
  • 30. Distributed SOA – “After” JBI Container Network Celtix Celtix Celtix Artix Tomcat Container AMQP AMQP AMQP MQ AMQP JMS Mainframe Spring-based Container
  • 31. How Does IONA Provide Distributed SOA?
    • Endpoint architecture
        • Service enablement is done at the endpoints of the network, without the need for a central hub
        • Qualities of service, including security, transactions, load balancing, etc. all done at the endpoints
    • Standards-based, technology neutral, extensible
        • Interoperates with broad array of technologies
        • Works with best-of-breed tools customers already use like AmberPoint, Systinet, existing messaging systems, and other middleware components
    • Supports Incremental Adoption
        • Technically and economically
  • 32. Complementary Open/Closed Source
    • Performance demanding, distributed Java environments that adhere to widely adopted standards
    • Organizations where SOAP & XML over HTTP & JMS are the primary required transports and where next-generation, popular development approaches such as REST, Web 2.0, Spring and others are being adopted
    • Instances in which easily accessible and affordable lightweight, embeddable SOA enablement is required, such as use by ISVs, other open source projects or homegrown applications
    • Performance demanding, distributed environments, where infrastructure software must run natively on multiple hardware and software platforms including the mainframe (i.e. CICS, IMS, COBOL, C++, etc.).
    • Where interoperability with multiple transports (i.e. MQSeries, TIB RV, Tux, etc.) is a requirement
    • Where enterprise Quality of Service, such as sophisticated transaction support, (i.e. distributed transactions, basic roll back), security integration and high availability are crucial
    Celtix Artix
  • 33. Complementary Open/Closed Source Plugging AMQP into existing MQ* Anything over MQ
    • Imagine two applications currently using MQ for messaging…
    • Now we add the Artix kernel (ART) but maintain the status quo
    Anything over MQ
    • Now we make a small configuration change to the WSDL
    Anything over AMQP * Artix AMQP Transport availability planned for 2007
  • 34. Open Source Support the Enterprise Way
    • Enterprise-class service and support customers expect from IONA with project committers on staff
    • Free 30 Day Evaluation Support
    • Developer Support
        • Priced per incident
    • Standard Support
        • Delivered during normal business hours
        • Priced per server
    • Enterprise Support
        • Available 24X7
        • Industrial strength SLA
        • Priced per server
    • Training & Consulting
  • 35. Summary
    • Complementary Open/Closed Source: IONA provides leading edge, patented micro-kernel architecture and pluggable framework to deploy a true distributed SOA environment via complementary open and closed source offerings
        • Incremental adoption
        • Dynamic & Adaptable
        • Technology neutral
    • Credibility: Leadership and significant investments for key Open Source SOA projects and standards along with 15 years of demonstrated experience in service-oriented IT environments
    • Transparency: Same support and warranties for Celtix Enterprise as Orbix and Artix product families
  • 36. For More Information
    • SOA White Papers
        • www.iona.com /whitepaper
    • Webcast Replays
    • www.iona.com/webcasts
    • Download Artix
      • www.iona.com/downloads/artix.htm
    • Download Celtix
      • www.iona.com/downloads/celtix.htm
  • 37. Questions