Session 06 ISYS90048 SM2 2019 22 Because an ESB architecture controls the way

Session 06 isys90048 sm2 2019 22 because an esb

This preview shows page 22 - 29 out of 38 pages.

Session 06 ISYS90048 SM2 2019 22
Image of page 22
Without ESB Session 06 ISYS90048 SM2 2019 23 Too many point-to-point links Multiple protocols, different qualities of service No clear picture of available services Many applications communicating with each other
Image of page 23
Cleaning up the mess Session 06 ISYS90048 SM2 2019 24 Now that you know that systems do not exchange information directly (i.e., loosely coupled) and you understand what a service is, you can start making use of an ESB App 4 App 3 App 5 App 6 App 1 App 2 App 1 App 3 App 2 App 6 App 5 App 4 ESB
Image of page 24
Key Differences between SOA & ESB Session 06 ISYS90048 SM2 2019 25 SOA is an architectural approach where we use ‘services’, whereas ESB is a technical implementation that aids in delivering a SOA SOA brings cost effective, reusable and low lead time solutions to an organisation whereas ESB enables low cost integration SOA is way of building the next generation of applications from ‘Lego blocks’ called Services whereas ESB is a piece of infrastructure software that provides APIs for developers to create services and send messages between services SOA is just like a car and ESB is like a road on which this car runs
Image of page 25
ESB Summary Session 06 ISYS90048 SM2 2019 26 An enterprise service bus should be considered as an architecture style or pattern and not as a product There is no definition or specification for the ESB and therefore no standard An ESB can help achieve looser coupling between systems A service on an ESB is stateless: No information is retained by either sender or receiver
Image of page 26
Adoption of Standardised Data Interchange Session 06 ISYS90048 SM2 2019 27 Driving forces: Semantic (language), technical and organisational interoperability – easier exchange of data Reduced development times – through use of existing standards for database design and existing software modules Reduced maintenance costs – through use of standardised modules Inhibiting forces: Costs to develop and propagate standard definitions Costs to change-over from existing to new, standardised systems Lack of clear industry-adopted standards Organisational changes – mergers, acquisitions, new entrants and substitutions
Image of page 27
Adoption of Standardised Communication Protocols Session 06 ISYS90048 SM2 2019 28 Driving forces: Semantic, technical and organisational interoperability over networks – easier exchange of data Reduced development times – through use of existing standards for network protocols
Image of page 28
Image of page 29

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture