Introduction to Service-Oriented Architecture and Enterprise Service Bus. Introduction to IBM Websphere ESB

1. Enterprise Service Bus
SERVICE ORIENTED ARCHITECTURE
Eng. Mahmoud Ezzat
Senior Software Engineer

2. Agenda
1. Architecture
2. Service-Oriented Architecture
• Overview
• What is a Service?
• Characteristics of a Service
• Reference Architecture
3. Enterprise Integration Pattern
4. Enterprise Service Bus
5. IBM Websphere ESB
• Common Used Patterns
• Service Component Architecture

3. Architecture

4. Architecture
• Architecture implies a consistent and coherent design approach.
Essential principles include:
• Consistency: The same challenges should be addressed in a uniform
way.
• Reliability: The structures created must be fit to purpose and meet the
demands for which they are designed.
• Extensibility: A design must provide a framework that can be
expanded in ways both foreseen and unforeseen.
• Scalability: The implementation must be capable of being scaled to
accommodate increasing load by adding hardware to the solution.

5. Service-Oriented Architecture
OVERVIEW

6. Service-Oriented Architecture
Overview
SOA is the architectural style that supports loosely coupled
services to enable business flexibility in an interoperable,
technology agnostic manner. SOA consists of a composite set
of business-aligned services that support a flexible and
dynamically re-configurable end-to-end business process
realization using interface-based service descriptions.

7. Service-Oriented Architecture
Overview
Providing a method to disconnect the service provider (service
capability which delivers a defined action) from the service requester
(client that sends the request).

8. Service-Oriented Architecture
WHAT IS A SERVICE?

9. Service-Oriented Architecture
What is a Service?
• A service is a reusable component that can be used as a building
block to form larger, more complex business-application
functionality.
• A service may be as simple as “get me some person data,” or as
complex as “process a disbursement.”

10. Service-Oriented Architecture
What is a Service?
• A service provides a discrete business function that operates on
data. Its job is to ensure that the business functionality is applied
consistently, returns predictable results, and operates within the
quality of service required.
• How the service is implemented, and how a user of the service
accesses it, are limited only by the SOA infrastructure choices of the
enterprise.
• From a theory point of view, it really doesn’t matter how a service is
implemented.

11. Service-Oriented Architecture
CHARACTERISTICS OF A SERVICE?

12. Service-Oriented Architecture
Characteristics of a Service?
• Supports open standards for integration: Although proprietary
integration mechanisms may be offered by the SOA infrastructure,
SOA’s should be based on open standards. Open standards ensure
the broadest integration compatibility opportunities.
• Loose coupling: The consumer of the service is required to provide
only the stated data on the interface definition, and to expect only
the specified results on the interface definition. The service is
capable of handling all processing (including exception processing).

13. Service-Oriented Architecture
Characteristics of a Service?
• Stateless: The service does not maintain state between invocations.
It takes the parameters provided, performs the defined function,
and returns the expected result. If a transaction is involved, the
transaction is committed and the data is saved to the database.
• Location agnostic: Users of the service do not need to worry about
the implementation details for accessing the service. The SOA
infrastructure will provide standardized access mechanisms with
service-level agreements.

14. Service-Oriented Architecture
REFERENCE ARCHITECTURE

15. Service-Oriented Architecture
Reference Architecture

16. Enterprise Integration Patterns

17. Enterprise Integration Patterns
Why Do We Need Integration?
What Makes Integration so Hard?
How can Patterns Help?

18. Enterprise Integration Patterns
• Integration Styles document different ways applications can be integrated. These
patterns present somewhat of a historical account of integration technologies. All
subsequent patterns follow the Messaging style.
• Channel Patterns describe the fundamental attributes of a messaging system. These
patterns are implemented by most commercial messaging systems. This section
focuses on the interrelationships between different features and highlights
implementation trade-off made by different vendors.
• Message Construction Patterns describe the intent, form and content of the messages
that travel across the messaging system. The base pattern for this section is the
Message pattern.
• Routing Patterns discuss mechanisms to direct messages from a sender to the correct
receiver. Message routing patterns consume messages from one channel and
republish the message to another channel that is determined by a varying set of
conditions. The message content is not modified. The patterns presented in this
section are special cases of the Message Router base pattern.

19. Enterprise Integration Patterns
• Transformation Patterns change the information content of a message. In many
cases, a message format needs to be changed due to different data formats
used by the sending and the receiving system. Data may have to be added,
taken away or existing data may have to be rearranged. The base pattern for
this section is the Message Translator.
• Endpoint Patterns describe the behavior of messaging system clients. They
illustrate different ways in which applications can produce or consume
messages.
• System Management Patterns provide the tools to keep a complex message-
based system running. A message-based integration solution can process
thousands or even millions of messages in a day. Messages are generated,
routed, transformed and consumed. The solution has to deal with error
conditions, performance bottlenecks and changes in the participating systems.
Message management patterns address these requirements.

20. Enterprise Integration Patterns
• Examples
http://www.enterpriseintegrationpatterns.com/toc.html

21. Enterprise Service Bus
IMPLEMENTATION OF ENTERPRISE
INTEGRATION PATTERNS

22. Enterprise Service Bus
An "Enterprise Service Bus" (ESB) is a system to which all
services are connected. Through the enterprise service bus
all connected services can also be accessed.
Implement Enterprise Integration Patterns

23. Enterprise Service Bus
• An ESB is used to connect the service requester to the service
provider so that messages can be routed between the two
platforms.
• The ESB is a collection of software components that manage
messaging from one part of the network to another.
• The ESB handles mismatches between the requesters and
providers, including protocol, interface or quality of service
mismatches.

24. Enterprise Service Bus
• The ESB processes messages exchanged between the service
endpoints.
• In contrast with regular business application components, the ESB is
concerned with the flow of the messages through the infrastructure
and not just with the business content of the messages. Rather
than performing business functions.
• The ESB performs mediation capabilities including, routing,
transformation, and logging operations on the messages.

25. Enterprise Service Bus
• An Enterprise Service Bus which
acts as central "bridge" or
"gateway" to all applications
exposing services underneath it.
• The term "bus" is an analogy to
the internal bus of a computer
onto which the CPU, RAM and
other chips are connected. An
enterprise service bus is typically
implemented as a server or a set
of servers, and is thus more than
just a "network".

26. Enterprise Service Bus
• Clients and services connected to an enterprise service bus do not
communicate directly. They communicate via the ESB.
• This is done by having the ESB essentially expose the same service
interface to potential clients, that the connected services expose to
the ESB.

27. Enterprise Service Bus
ESB as Single Point of Access
• One advantage of connecting clients and services via an enterprise
service bus is that clients need only look for services in a single
location: The enterprise service bus.
• If a service is moved from one server to another, you only need to
reconfigure the ESB. The clients still just access the service via the
ESB.

28. Enterprise Service Bus
ESB as Transaction Manager
• ESB can coordinate distributed
transactions which multiple
services participate in.
• When multiple distributed
services need to participate in a
transaction some entity typically
has to coordinate the
transaction. Rather than forcing
the client to do this, the
enterprise service bus can do so.

29. Enterprise Service Bus
ESB as Security Manager
• Security aspects like
authentication and
authorization can be
centralized in the enterprise
service bus. Even if a service in
an application does not have
authentication and
authorization, the enterprise
service bus can require this in
the service interface it exposes
to potential clients.

30. Enterprise Service Bus
ESB as Service Proxy
• An ESB may function as a gateway or
proxy for applications that do not
expose a standardized service
interface to the world. For instance,
lets say an application exposes a
Java RMI service. The rest of your
network is running on .NET which
cannot directly call the RMI service.
• To solve this problem you can
implement a service proxy in Java
which can call the RMI service. The
service proxy then exposes a web
service interface (SOAP + WSDL) via
the ESB to the .NET applications.

31. Enterprise Service Bus
ESB as Gateway to the World
• If some clients need to connect
to services running in the outside
world, the ESB can potentially
function as a gateway to the
world outside. Again, security
aspects etc. can be added on top
of the external service.
Furthermore, if the external
service is capable of participating
in distributed transactions, the
ESB can coordinate this too.

32. IBM Websphere ESB

33. IBM Websphere ESB
Websphere ESB is designed to provide an ESB for IT environments
built around open standards and SOA. It delivers easy to use
functionality that is built on the messaging and web services
technologies of Websphere Application Server.

34. IBM Websphere ESB
• Websphere Integration Developer, is the tool for use with Websphere
ESB. It is designed to build applications that will be deployed to either
Websphere ESB or Websphere Process Server.
• WebSphere ESB supports connectivity between endpoints through a
variety of protocols and application programming interfaces (APIs) such
as:
• WebServices SOAP 1.1 and 1.2
• Java Message Service (JMS) 1.1
• WebSphere MQ
• Enterprise Java Bean (EJB) Stateless Session Bean
• HTTP
• Enterprise Information Systems (EIS) integration using WebSphere Adapters

35. IBM Websphere ESB
COMMON USED PATTERNS

36. Simple Service Proxy Pattern

37. Service Selector Pattern

38. Service Translator Pattern

39. Service Gateway Pattern

40. Message Enrichment Pattern

41. Batch Aggregation Pattern

42. Multiple Source Aggregation Pattern

43. IBM Websphere ESB
SERVICE COMPONENT ARCHITECTURE

44. Service Component Architecture
• Module, A unite of deployment, where services are packaged
together.
• Modules can include:
• Service components, that hold the business function within a module.
• Imports, that are calls to services external to the module.
• Exports, that are used to expose components to callers that are external to
the module.
• Interfaces, which can be associated with one or more components.
• Stand-alone references or reference applications that are not defined as SCA
components (for exemple, JavaServer Pages).
• Other elements, for example WSDL files, Java classes, XSD files.

45. Service Component Architecture – Module Structure

46. References
• WebSphere Enterprise Service Bus - Development Guid
• IBM ESB Paper:
http://www.eecg.utoronto.ca/~jacobsen/courses/ece1770/reader06/paper-
esb1.pdf
• http://tutorials.jenkov.com/soa
• http://www.enterpriseintegrationpatterns.com/
• http://www.javaworld.com/article/2071889/soa/what-is-service-oriented-
architecture.html
• http://www.j2mesalsa.com/soa/intro.php
• http://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20I
ntroduction%20to%20SOA.pdf