Editor's Notes
- #4: 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.
- #5: 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.
- #6: Call out the continuing trends that is expected to spearhead the future of the computing
- #7: 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
- #9: Concept Refresh .. Not to spend more than a minute here
- #10: Concept Refresh .. Max 5 mts
- #11: Concept Refresh .. Max 3 minutes
- #12: 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.
- #34: “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