The Intricacies Of Enterprise Integration Soa Vs Esb


Published on

Published in: Technology, Business
1 Comment
  • This is an excellent presentation! It succinctly covers the salient points and provides solid guidance.
    Are you sure you want to  Yes  No
    Your message goes here
  • 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
  • Intent here is to start the discussion with this thought….Gather industry feedbackBurton Group analyst Anne Thomas Manes set off a storm of IT industry chatter around the viability of SOA when she pronounced that service-oriented architecture is dead and the recession killed it. Manes says the term SOA itself is a problem. However, services and service orientation, as well as mashups, business process management, SAAS and cloud computing—all SOA-related technologies—will continue to gain importance.SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM [business process management], SaaS [software as a service], Cloud Computing, and all other architectural approaches that depend on 'services.'\"SOA\" is no longer viable as a selling point to businesses because it connotes big, expensive projects, she noted that the basic tenets of SOA remain critical.Once thought to be the savior of IT, SOA instead turned into a great failed experiment—at least for most organizations. SOA was supposed to reduce costs and increase agility on a massive scale. Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever. The people holding the purse strings have had enough. With the tight budgets of 2009, most organizations have cut funding for their SOA initiatives.
  • Explain the rationale behind the very thought ‘SOA – Dead or Alive’The Winchester Mystery House is a classic example of an implementation without an architecture. The Winchester Mystery House is an intriguing tourist attraction in the USA near San Jose, CA. Tell story of its history38 years of non-stop construction – 147 builders 0 architects160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors65 doors to blank walls, 13 staircases abandoned, 24 skylights in floorsNo architectural blueprint existsSo as you can see, implementation and architecture are two vastly different things that are clearly co-dependent. The next time you read an article that tries to explain SOA and then jumps immediately into language or platform-specific guidance realize that they are not providing architectural guidance, they are providing coding guidance. This is one of the many reasons that SOA is so misunderstood today.
  • Call out the continuing trends that is expected to spearhead the future of the computing
  • Bring in the S+S messaging by mentioning the culmination of various trends. Messaging here is to indicate the prominence of ‘Services’ going forward, and tie it down to the session agenda
  • Concept Refresh .. Not to spend more than a minute here
  • Concept Refresh .. Max 5 mts
  • Concept Refresh .. Max 3 minutes
  • 5 minutes….Source: ESB Myth Busters: 10 Enterprise Service Bus Myths Debunked -> Dave ChappellMyth #1:According to Forrester Research, an ESB helps enterprises obtain the value of SOA by increasing connectivity, adding flexibility that speeds change, and providing greater control over use of the important resources that it binds.An ESB can be used to handle integration projects that have traditionally been relegated to EAI tools. However, an ESB can also be used for establishing B2B relationships across companies.An ESB provides EAI capabilities, but is based on a fundamentally different architecture that is providing the basis of an industry transition from traditional integration to coordinated service interaction. EAI brokers are historically implemented as a monolithic stack, using centralized hub-and-spoke architectureMyth #2:As part of the evolving standards process of Web services specifications, there exists much uncertainty due to the many overlapping efforts underway. As these specifications mature and achieve widespread adoption, they will still require an infrastructure to support them. An ESB can provide a consistent model for building, orchestrating, and managing SOAs, while insulating the IT organization from changes in underlying interoperability standardsA WS-Reliability implementation requires that there be an industry-proven reliable message persistence and store-and-forward processor to support it. A foundational component of an ESB is an enterprise messaging layer that provides quality of service of message delivery through messaging conventions such as message persistence, store- and-forward delivery, message acknowledgements, and interfaces with external XA-compliant transaction managers. The ESB implementation may also provide transparent routing of messages across sophisticated network topologies, and continuous availability of the messaging infrastructure through a fault-tolerant messaging server architecture. The science of making all of this work together to ensure reliability under high-stress enterprise environments requires many person-years of effort to get right. That being said, ESBs that are implemented today using a proprietary messaging layer should also adopt one or more of the WS-Rel* as additional protocols or \"on-ramps\" for getting on and off the bus. However, it is not a one-size-fits-all solution and many combinations of messaging and protocol support are necessaryMyth #3: The term \"Enterprise Service Bus\" (ESB) is not really a product category; it is simply an abstract concept that can be applied toward a coupling of an existing application server and integration middlewareMyth #4: An ESB may support multiple ways of coordinating the interaction between event-driven service invocations using formal business process definitions. BPEL (Business Process Execution Language) is one way of doing it, and there are others as well. An ESB also has itinerary-based routing, which provides a message with a list of routing instructions. These routing instructions, which represent a business process definition, are carried with the message as it travels through the Bus across service invocations. The remote ESB service containers determine where to send the message next. Myth #5: There is a new breed of IDE, which Gartner Group refers to as an ISE (integrated services environment), that allows you to design, configure, test, and debug the integration services that you develop when building an SOA with an ESB. Using a graphical interface, an integration architect draws diagrams using UML notation to describe process definitions. You may also use the ISE to graphically create data transformations between different data formats, and create and debug XSLT style- sheets.
  • “Service Excellence Everyday” – Single View of Customer ( .Net Smart Client, Web Services, 1700 Sites, All Call Centers, Reuse -> Win32 Front end assets, mainframe & legacy systems)2K to 30K Users1100 Branches- Any one time, they have 18K connected usersThought ProcessThey had very slow network 64 K link – 5 people working Perception of responsiveness
  • The Intricacies Of Enterprise Integration Soa Vs Esb

    1. 1. Sandeep Alur Aditee Rele Architect Advisor Architect Advisor Microsoft India Microsoft India
    2. 2. Is SOA Dead or Alive ?
    3. 3. Big Projects Connotes Expensive
    4. 4. Momentum Continues…
    5. 5. Industry Trends SOA: Service Oriented Architecture RIA: Rich Internet Applications Reuse and Agility Experience Software + “Services” SaaS: Software as a Service Web 2.0 Flexible pricing and delivery Network Effect Cloud Computing Service Utility
    6. 6. Next One Hour SOA & ESB – Big Buzz Words Reality Check – Myths Application Integration – Patterns Reasons to go for SOA Technology Stack for SOA Reasons to go for ESB Technology Stack for ESB ‘Service Orientation’ – Technology Puzzle Success Story
    7. 7. Demystifying SOA Modular Distributable SOA SOA Clearly defined Swappable Sharable SOA
    8. 8. Common Myths about SOA Myths Facts 1. SOA is a technology 1. SOA is a design philosophy independent of any product, 2. SOA require Web Services technology or industry trend 3. SOA is new and revolutionary 2. SOAs may be realized via web services but using web services will not 4. SOA ensures the alignment of IT and necessarily result in a SOA business 3. EDI, CORBA and DCOM were 5. A SOA Reference Architecture conceptual examples of SOA reduces implementation risk 4. SOA is not a methodology 6. SOA requires a complete technology 5. SOAs are like snowflakes – no two are and business processes overhaul the same. 7. We need to build a SOA 6. SOA should be incremental and built on your current investments 7. SOA is a means, not an end
    9. 9. Demystifying ESB Middleware Infrastructure Manifestation of SOA ESB ESB Communication & Mediation Connects Providers & Consumers ESB
    10. 10. Common Myths about ESB Myths Facts 1. ESB is just a new name for 1. ESB provides EAI capabilities, but based on different architecture EAI 2. Provides a Enterprise Messaging 2. Adoption of WS-* specs Layer (Not a one size fits all obviate the need for ESB solution) 3. An abstract pattern that can be 3. Pattern or Product applied to couple an existing app 4. ESBs will be obsolete once server and integration middleware BPEL is widely available 4. ESB may support multiple ways of coordinating the interaction 5. ESBs are simply plumbing between event-driven service and do not provide invocations using formal business process definitions sophisticated tooling 5. Integrated Services Environment
    11. 11. Application Integration Patterns
    12. 12. 3 Patterns of Application Integration Style Data Consistency Latency Scheduled to immediate Prevailing Asynchronous, one Interaction Style way Flow Management Generally, simple scheduled batch jobs or immediate messaging Application Applications remain Dependencies logically and 1 physically independent
    13. 13. 3 Patterns of Application Integration Style Multistep Process Latency Scheduled to immediate Prevailing Asynchronous, one way Interaction Style Flow More-complex batch job Management streams; sophisticated orchestration using BPM technologies Application Applications remain Dependencies physically independent but are logically dependent from 2 the perspective of completing the Process
    14. 14. 3 Patterns of Application Integration Style Composite Application Latency Immediate Prevailing Two-way synchronous and Interaction Style Partially Synchronous Flow Complex interactions may Management be controlled by application code or using BPM technologies or other tools Application Applications are logically Dependencies and physically highly 3 Dependent
    15. 15. When to 'SOA'
    16. 16. Reasons to go for SOA When designing most large, new business applications and processes SOA When integrating a combination of COTS, legacy and services from other BU’s Generalization (Service Orientation) Use non-SOA styles for tactical applications of limited size
    17. 17. Technology Stack for SOA Consumers WCF Endpoints Windows Communication Foundation (.Net Framework 3.x) Protocol Supports WS-* Host Independence (WSE) (Custom or IIS)
    18. 18. SOA Reference Architecture
    19. 19. When to 'ESB'
    20. 20. Reasons to go for ESB Multiple Communication Protocols Intelligent Addressing, routing & ESB Orchestration Mediation Complementing Application Platforms
    21. 21. Multiple Communication Protocols HTTP/SOAP MSMQ MQ Series TCP File Messaging Infrastructure One way Messages Reliable Messaging 2 Way – Request/Response Explicit Support for REST Store & Forward WCF Publish - Subscribe SCA
    22. 22. Addressing, Routing & Orchestration Service Virtualization Rule Based Routing Orchestration HTTP/SOAP MSMQ MQ Series TCP File Messaging Infrastructure Itinerary Service Registry Line of Business Applications
    23. 23. Mediation Message Message A Source X Destination S E C Message Message U B X R I T Y Message Message X C Message Validation Transformation Protocol Binding Message Logging & Auditing Security
    24. 24. Complementing Application Platforms HTTP/SOAP MSMQ MQ Series TCP File Messaging Infrastructure Load Balancing Failover Transaction Management
    25. 25. ESB(Guidance Kit) Technology Stack Addressing Multiple Communication Protocol Transformation & Routing Service Registry Administration
    26. 26. Industry Innovations Service Life Graphical Cycle Management Editing Tools Extended Functions Core Functions SLA Dynamic Protocols, Monitoring/ Service Management Transformation, Provisioning Routing, Standard Formats, Error Handling, Security, Integration, Extensibility, High availability & Scalability Business Business Activity Rules Engine Monitoring (BRE) (BAM) Complex Event Processing (CEP)
    27. 27. Application Platform for 'Services'
    28. 28. Application Platform for 'Services' Consume User Directed Compose SOA as User Experience and Interaction mechanism People using Content, BI, to interact Collaboration and Communication Standards based Interoperability Compose SOA as Business Process Services mechanism Information Integration to transact Messaging Services Communication Services Expose Existing Systems
    29. 29. Application Platform for 'Services' Consume User Directed Portals, Web Parts, Smart Client, Office Client Extensions, Mobile Client Management and Governance Compose Real Time Unified Communications, Design and Development Online P2P Offline Collaboration Security and Identity User Interaction Workflow, Search, Dashboards, KPIs, Doc and Forms Libraries, Business Data Catalog Orchestrations Rules, BAM, ETL, Federated ESB, EAI, P2P, Qu Compose Trading Partner Access, MDM eues Mgmt Business Transaction ESB, EAI, P2P, Queues Expose Existing Systems
    30. 30. Application Platform for 'Services' Consume User Directed Visual Studio, Patterns and Practices, MSF SharePoint Server, .NET Compact Framework, Silverlight,Office System, ASP.NET, Windows Client Compose System Center, Partners Live Communications Server, SharePoint Server User Interaction Active Directory Workflow Foundation, SharePoint Server, CAB Enterprise Service Bus (BizTalk Server 2006 R2) WCF BizTalk SQL Server Windows Compose Server BizTalk Server Business Transaction AmberPoint WCF and BizTalk Server Expose Existing Systems
    31. 31. Case Study - 3 Tenets of Enterprise Integration
    32. 32. Solution Highlights “Service Excellence Client Tier WinPart Everyday” Agent Local 1100 Branches, 30K WS Proxy Cache User Base Private Services 18K Connected Any SOFA Instrumentation given time Configuration Private Authentication/ Security Config Services Authorization Perception of Service Helpers Data Integration Orchestration Responsiveness Legacy Systems Reuse->Mainframe & SOFA Data Storage Legacy Systems/Assets IFW Service .Net Smart Client with Service Integration Mainframe
    33. 33. In Summary ‘ESB’ is a manifestation of SOA SOA is an overtly used term and forms the basis for a ‘Services’ platform While, new architectural patterns emerge, SOA continues to fuel energy Beginning of a new Era…
    34. 34. Momentum Continues…
    35. 35. © 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.