What is SOA and ESB and how can it fit into your organization?

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.

5. Requirements

6. Refreshments

7. Time Frame

8. About evosolutions

9. About You

10. SOA & ESB Overview The What, Why, Where, and When of SOA and ESB

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

51. Proof of concept with live data!

53. Reduce or eliminate need for compiled highly managed code.

54. Easing future development staff resource requirements

55. Reducing cost per transaction

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.