SlideShare a Scribd company logo

SOA & ESB Presentation

•
•
E
erichleipold

SOA is an approach to software design based on modularizing business logic and functions as loosely coupled services. An ESB is a distributed infrastructure that provides foundational services like message routing and transformation to enable complex architectures. While an ESB does not implement an SOA itself, it provides key features to build an SOA. ESBs should be standards-based and flexible to support different transport mediums.

1 of 16
SOA vs. ESB Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application's business logic or individual functions are modularized and presented as services for consumer/client applications. What's key to these services is their loosely coupled nature
An Enterprise Service Bus (ESB) is a distributed infrastructure used for integration consisting of a set of service components and data adapters, which connect various types of services. ESB's provide an abstracted layer over a reliable messaging middleware infrastructure . The ESB provides foundational services for more complex architectures via an event-driven and standards-based messaging engine (the bus). The ESB provides services for transforming and routing messages, as well as the ability to centrally administer the distributed system.
ESB does not implement a service-oriented architecture (SOA), but provides the features with which one may be implemented.. ESB should be standards-based and flexible, supporting many transport mediums.
Introduction Agenda
Requirements
Refreshments
Time Frame
About evosolutions
About You
SOA & ESB Overview The What, Why, Where, and When of SOA and ESB
What is SOA? Service-Oriented Architecture
A business-driven approach to software design. Helps you gain complete visibility of information across your organization and business partner/client integrations More of a design ideology than a technology.
Based on the key concepts of an application front-end, service, service repository, and a service bus.
Functionally separated by logical business units.
Is not implemented on a specific platform or with a particular programming language. This loosely coupled approach allows enterprises to plug in best of class solutions, new services or upgrade existing services in a granular fashion to rapidly address new business requirements.
Why is SOA Important? Services are designed and developed as small building blocks that are used to build the enterprise SOA.

More Related Content

SOA & ESB Presentation

  • 1. SOA vs. ESB Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application's business logic or individual functions are modularized and presented as services for consumer/client applications. What's key to these services is their loosely coupled nature
  • 2. An Enterprise Service Bus (ESB) is a distributed infrastructure used for integration consisting of a set of service components and data adapters, which connect various types of services. ESB's provide an abstracted layer over a reliable messaging middleware infrastructure . The ESB provides foundational services for more complex architectures via an event-driven and standards-based messaging engine (the bus). The ESB provides services for transforming and routing messages, as well as the ability to centrally administer the distributed system.
  • 3. ESB does not implement a service-oriented architecture (SOA), but provides the features with which one may be implemented.. ESB should be standards-based and flexible, supporting many transport mediums.
  • 10. SOA & ESB Overview The What, Why, Where, and When of SOA and ESB
  • 11. What is SOA? Service-Oriented Architecture
  • 12. A business-driven approach to software design. Helps you gain complete visibility of information across your organization and business partner/client integrations More of a design ideology than a technology.
  • 13. Based on the key concepts of an application front-end, service, service repository, and a service bus.
  • 14. Functionally separated by logical business units.
  • 15. Is not implemented on a specific platform or with a particular programming language. This loosely coupled approach allows enterprises to plug in best of class solutions, new services or upgrade existing services in a granular fashion to rapidly address new business requirements.
  • 16. Why is SOA Important? Services are designed and developed as small building blocks that are used to build the enterprise SOA.
  • 17. Closest attempt to define services in terms of business functionality. The gap between business and technology workflows is narrowed and is made more intuitive.
  • 18. Allows users to define work flows with BPM (business process management) tools or BPEL (Business Process Execution Language) via drag and drop user interfaces.
  • 19. Allows applications in heterogeneous environments to be defined as a single system. Best of class solutions can be implemented regardless of underlying infrastructure.
  • 20. Where Should SOA Be Applied? Initially SOA should be applied to a discrete existing or soon to be realized business unit or workflow.
  • 21. The next logical step is to apply SOA consistently to other business units.
  • 22. With proper planning, it will encompass most, if not all, of the enterprise and external integrations.
  • 23. The end result will be segregated business processes, interacting with each other through integration points.
  • 24. When Should SOA Be Applied? An SOA should be implemented after careful consideration and definition of business units and the business processes that support those units. That said a solid ESB foundation speeds up adaptation and eases planning and deployment.
  • 25. The first SOA implementation, applied to a discrete business unit, is usually a good indicator of the time and resources required to implement the remainder of the SOA.
  • 26. Exceptions may occur when business units and/or functions overlap and are difficult to segregate. In those cases, extra design time should be allocated for the implementation.
  • 27. What is an ESB? Enterprise Service Bus (more than just another acronym)
  • 28. Is the foundation of a well-designed SOA environment.
  • 29. Provides a framework for the transformation, processing, routing, and monitoring of both simple and complex data.
  • 30. Some products, such as Mule ESB and Fiorano SOA, incorporate integration toolsets to make their ESB more intuitive, robust and full-featured, reducing development time.
  • 31. By definition, should be standards-based and platform-independent. The core language that it is used, such as Java or .NET, does not limit its ability to co-exist with current and future solutions.
  • 32. What is an ESB (continued)? Pre-built, third party, and customized services are available to handle all standard and most lesser known protocols such as JMS, HTTP, SOAP, FTP, SMTP/POP3 etc.
  • 33. Pre-built, third party, and customized adapters are available to handle data access and manipulation via ODBC, JDBC, XML, EDI, File, FTP, SMTP/POP3 etc. as well as many legacy mainframe and less commonly used data sources and types.
  • 34. Configurable routing allows messages to be passed to one or more endpoints either synchronously , asynchronously or concurrently, even between disparate messaging platforms.
  • 35. Provides transaction, logging and error handling management for complex services that could span several endpoints both internally or externally to the system.
  • 36. Why is an ESB Important? Allows for loose coupling of components and processes.
  • 37. Provides flexibility for changing and integrating applications.
  • 38. Typically incorporates industry-standard data transports that are understood by most IT professionals, therefore bringing commonality to an otherwise complex landscape.
  • 39. Centralizes global functions, such as logging, security, and administration.
  • 40. Allows data to be routed to multiple destinations, reducing the number of point-to-point connections. Allows Enterprises to quickly respond to business changes with agility; leverage existing investments to address new business requirements or to extend current capabilities.
  • 41. Where Should an ESB Be Implemented? Like SOA, an ESB should initially be implemented on a discrete portion of the enterprise. This allows business analysts, system administrators, and developers to become accustom to the ESB within an easily-managed space.
  • 42. ESB's are inherently designed for integration points and, therefore, should be used at any logical endpoint between internal applications, external applications, and systems.
  • 43. When Should an ESB Be Implemented? The greatest advantage of a light-weight, flexible ESB is that it can be implemented immediately to a discrete portion of the enterprise without impacting the entire enterprise.
  • 44. Implementing an ESB is typically the first step in applying a Service-Oriented Architecture to the enterprise; however, an ESB does not require the application of an SOA.
  • 45. Due to the nature of ESB's, a POC (proof of concept) lends itself well to a non-intrusive demonstration of their capabilities.
  • 46. Applications for an ESB Extending the life of legacy applications and data sources.
  • 47. Integrating software from different platforms, business partners, or vendors. Creating integration points for disparate back-end systems, vendors, customers, and other external entities.
  • 48. Migrating from one software application to another. An ESB allows staged migration with proper planning avoiding "flip of the switch" scenarios and rollbacks.
  • 49. Wherever scalability and guaranteed delivery is desired.
  • 50. Testing (even in production) *** Rapid change management
  • 51. Proof of concept with live data!
  • 52. Integrating systems with recent business acquisitions . Integration of system and network level administration and monitoring with business level workflows.
  • 53. Reduce or eliminate need for compiled highly managed code.
  • 54. Easing future development staff resource requirements
  • 55. Reducing cost per transaction
  • 56. ESB FAQs and Misconceptions I don't have the time to implement an ESB in my organization. The advantage of SOA and, in particular, a good ESB is that you can implement small portions of the ESB incrementally. How much will an ESB cost me? There are several options available. You can build your own for little or no licensing and support cost. You can also download an OpenSource package and decide what kind of support is feasible, including commercial support. The other option is to buy a commercially licensed and supported product. My systems are archaic – a Java-based ESB will not work. An ESB is designed to work with different technologies. It has the capabilities to interface with flat-files, FTP files, EDI documents, HTTP files, databases including the AS400, and any TCP-based technology. Will I have the resources available to maintain an ESB? Based on the level of management you wish to achieve, there are several viable options for maintaining your ESB. Tools are available for many of the packages that allow IT management to monitor and diagnose the SOA environment. Training is available for developers, architects, and system-level personnel. Consultants and contractors specialized in ESB technologies are available through evosolutions and its partners.
  • 57. ESB FAQs and Misconceptions All ESB's are based upon Web services Most good, flexible ESB's are able to product and consume Web services, but also offer many other We only have a couple of business applications. We don't need and ESB at this time. That is almost the best time to start. Developing an SOA strategy and implementing an ESB when your environment is not complex will cut down on the future implementation time. It also makes your systems very flexible and easier to integrate, therefore allowing you to make business decisions without worrying about your system capabilities. Which ESB should I choose? There are two ESB packages that we recommend. One is MuleESB, from MuleSource. It is commercially supported with multiple SLAs, offers indemnification, and is OpenSource. In addition, the new 2.0 version has separate community and enterprise editions. It is highly customizable, easy for developers to use, and very light-weight. The second package is Fiorano SOA. Fiorano comes with an ESB and a messaging system. It is centered around BPM (Business Process Management) with GUI tools, which makes it easier for technically-savvy business personnel to manage. Other ESB packages include WebSphere ESB (IBM), Tibco ESB, Oracle ESB, and JBoss ESB. The advantages of Mule and Fiorano over the others are speed, flexibility, price, and, most importantly, the ability to develop customized solutions.
  • 58. Summary SOA and ESB are very popular acronyms in today's business and technical worlds. SOA allows businesses the opportunity to develop a very flexible infrastructure to manage market changes, technical advancements, and third-party relationships more easily. IT resources can spend less time on developing communication methods and more time on developing business processes. On the other hand, management can focus more on strategic relationships, without worrying about the capabilities of their systems. In short, SOA is not necessarily a technology, rather a framework and language that allows business and technology to communicate on common ground.