1. 7. Service-oriented Architecture (SOA)
Part 2

2. The Evolution of SOA The analogy of A/V Components
September 15, 2018
The analogy of A/V Components
Years ago electronic systems were self-contained monolithic systems
Today’s gadgets are pluggable and independent
Standardized connections

3. A brief history

4. How did it come to SOA?

5. How did it come to SOA?

6. How did it come to SOA?

7. How did it come to SOA? Procedural Oriented Component Oriented
Object Oriented
Service Oriented
Procedural Oriented

8. A website selling gadgets
How did it come to SOA?
Ordering service
A website selling gadgets
Serving its customers
Tracking Service
Checkout service
Inventory service

9. How did it come to SOA?

10. Enterprise Application Integration

11. Enterprise Integration

12. Summing up: the Evolution of Distributed Computing
September 15, 2018
Summing up: the Evolution of Distributed Computing
How it all grew…
Downsize
(Client /Server)
Component
(CORBA, EJB/RMI, DCOM)
Messaging
MOM
Mainframe/Mid Range
Service Orientation

13. Application Service Evolution
September 15, 2018
Application Service Evolution
Service Oriented Design (Inter-Enterprise Scope)
Service Layer
Component Oriented Design
(Inter-Application Scope)
Component
Layer
Object Oriented Design
Class Layer
Structured design

14. Benefits of SOA Efficient and effective usage of ‘Business Services’
September 15, 2018
Benefits of SOA
Efficient and effective usage of ‘Business Services’
Greater agility
Loosely-coupled with reusable assets and services
Promotes productivity
Reduces time-to-market
Drives business processes closer to end users

15. Benefits of SOA Technology agnostic
September 15, 2018
Benefits of SOA
Technology agnostic
Leverage and integrate existing applications
Build, maintain & extend vs. rip and replace
Provide standard connections between systems
Abstract complexity for developers

16. Benefits of SOA September 15, 2018 Independence from technology
Adequate business
infrastructure
Agility
Reuse
Risk mitigation
Evolutionary
approach
Cost savings
More efficient
development process
Feedback at
different levels

17. September 15, 2018
Key components of SOA
Discovering SOA Analogy: “The 6 blind men and the Elephant”
WALL ?
SPEAR ?
FAN ?
ROPE ?
SNAKE ?
TREE ?

18. Different interpretation of SOA…
September 15, 2018
Different interpretation of SOA…
RESTful ?
BPEL ?
XML ?
SOAP?
ESB ?
Web services ?

19. Challenges Axis SOA Alphabet Soup What Would You Choose? JBI
September 15, 2018
Challenges
SOA Alphabet Soup What Would You Choose?
Axis
JBI

20. Associated Terminology
September 15, 2018
BPO
Business Process Outsourcing
BPM
Business Process Management
ESP
Enterprise Service Provider
GDM
Global Delivery Model
SOA
Service Oriented Architecture
SODA
Service Oriented Development of Applications
SOBA
Service Oriented Business Applications
SOE
Service Oriented Enterprise WS
Web Services

21. Message Brokering
Message brokering technology is a response to the challenge to build new integration applications without reprogramming existing applications.
Brokers sit on top of the common messaging protocol enabled by the messaging half adapters.
The common protocol exposes data traffic to and from applications.
Message brokers are integration servers that are located centrally between applications, for example, in a hub-and-spoke topology.

22. Evolution of Application Integration Patterns

23. Key Terms for a Service-oriented Architecture

24. Isolating the Business Process from the Implementation

25. Vision of the Service-Oriented Enterprise

26. Open Group SOA Reference Architecture (SOA RA)

27. Service-Oriented Architecture:
The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer.
Services can be
invoked,
published and
discovered,
and are abstracted away from the implementation using a single, standards-based form of interface.

28. SOA SOA is a Software Design Approach
Conceptually a collection of services on a network that communicate with one another.
Services are loosely coupled
SOA is a higher level of application development.
SOA typically leverages on standards based integration.
The key players include service provider and service consumer

29. SOA Components and Operations

30. SOA architecture Service Directory Registers Finds and Retrieves
September 15, 2018
SOA architecture
Service Directory
Registers
Finds and Retrieves
Service
Consumer
Service
Provider
Invokes

31. SOA Architecture

32. Basic Components of an SOA
SOA consists of the following three components:
Service provider
Service consumer
Service registry
Each component can also act as one of the two other components.
For instance, if a service provider needs additional information that it can only acquire from another service, it acts as a service consumer.

33. Service

34. Services, Services

35. A Service
A service is a unit of work done by a service provider to achieve desired end results for a service consumer
A service is a self-contained software module that performs a predetermined task:
"verify a customer's credit history," for example.
Services are software components that don't require developers to use a specific underlying technology.
The other key advantage of SOA is that it lets you automate business-process management.
Business processes may consume and orchestrate these services to achieve the desired functionality.
Thus, new business processes can be constructed by using existing services.

36. A Service
A service in SOA is an exposed piece of functionality with three properties:
The interface contract to the service is platform-independent.
The service can be dynamically located and invoked.
The service is self-contained. That is, the service maintains its own state.

37. Message Service providers and consumers communicate via messages.
Services expose an interface contract.
This contract defines the behavior of the service and the messages they accept and return.
Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language.
Therefore, messages are typically constructed using XML documents.

38. Dynamic Discovery
The directory service is an intermediary between providers and consumers.
Providers register with the directory service and consumers query the directory service to find service providers.
Embedding a directory service within SOA accomplishes the following:
Scalability of services; you can add services incrementally.
Decouples consumers from providers.
Allows for hot updates of services.
Provides a look-up service for consumers.
Allows consumers to choose between providers at runtime rather than hard-coding a single provider.

39. Dynamic Discovery
Dynamic discovery hints that a discovery service (e.g., a directory service) is available.
The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria.
For example, if I was looking for a credit-card authorization service, I might query the directory service to find a list of service providers that could authorize a credit card for a fee.
Based on the fee, I would select a service

40. A platform-Independent Interface
A platform-independent interface contract implies that a client from
anywhere,
on any OS, and
in any language,
can consume the service.

41. SOA Offers Several Key Advantages
You can:
Adapt applications to changing technologies.
Easily integrate applications with other systems.
Leverage existing investments in legacy applications.
Quickly and easily create a business process from existing services.

42. Business Requirements and Drivers for SOA

43. Greater Need for a Flexible Architecture
When using an SOA-based application, the services are defined as units of business logic separated from the flow of control and routing, and the data transformation and protocol transformation.
This approach provides loose coupling, thus making this approach much more flexible for integration.

44. Business Driving a Shift in IT

45. Enterprise Service Bus (ESB)

46. Overcoming the Problems of Point-to-point Integration with ESB

47. ESB as a Distributed Infrastructure with Centralized Control

48. SOA without ESB

49. SOA with ESB

50. The ESB Architecture
The purpose of the ESB is so that common specifications, policies, etc can be made at the bus level, rather than for each individual service.