KEMBAR78
Lecture 09 - 10 Routing Translators and Endpoints | PDF | Routing | Router (Computing)
0% found this document useful (0 votes)
9 views110 pages

Lecture 09 - 10 Routing Translators and Endpoints

Uploaded by

sokoclash123
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views110 pages

Lecture 09 - 10 Routing Translators and Endpoints

Uploaded by

sokoclash123
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 110

Integration

Patterns
Routing, Transformers
and Endpoints

1
Channels √
Basic
Components Routers
of Pipes and
Filters Translators
Architecture
Endpoints
2
Channels √
Basic
Components Routers
of Pipes and
Filters Translators
Architecture
Endpoints
3
Routing in the Last Lecture
• Recall the basic objective in using a messaging systems in a pipes
and filters architecture
• Decouple the sender from the receiver and modularize the system
components.

4
Routing in this lecture…
• Discuss several types of message routers and their use cases.
• Provide routing and brokering ability to our solution.
• Recalling the simple message router we discussed, all patterns
are refinements of that pattern.
• Simple Routers.
• Composed Routers.
• Architectural Patterns

5
Use the
Right
Router
for the
Right
Purpose

6
Multiple Inventories
• Suppose you are building aggregator system of services after an
acquisition or partnership.
• Or an E-retailer that provide items for purchase from multiple
sources
What do we want to do ?
• A message should be routed to its desirable service provider.
• An item in an order should be processed from the inventory.

7
Revisit old
patterns -
channels
Using pub-sub channel:
• Discard the irrelevant message
distributed coordination across multiple
systems.
cannot be processed by any system →
how should I know
more than one system can process the
order → duplicate shipments

8
Revisit old
patterns -
channels
Data type Channel:
• Listen on all the channels for those items
that it can process.
• leverages the channel addressability.
Many items could quickly lead to an
explosion of the number of channels
Run-time and management overhead.
Involvement of the sender.

9
Content-Based Router
• Encapsulates the fact that the business function is split across
systems.
• Efficient in its usage of message channels and message traffic.
• Ensures that the order is handled by exactly one inventory system.

10
Multiple Inventories / Promotions
• I still have the multiple inventories usecase but I am checking for
an item in all the locations.
• Company management publishes price changes and promotions
to large customers by sending a message notifying the customer.
• Customers are interested in specific items.

11
Message Filter
Router
• Pass on a Publish
subscribe channel to
broadcast the message.
• Then, use a message filter
to pick the item needed.
✓Adding a new subscriber is
easy.
High traffic.
• Multiple receivers of
promotions.

12
13
Message Filter Router Content Based Router
Message More than one consumer can Exactly one consumer receives each
Consumption consume a message message
Maintenance Distributed control and Central control and maintenance --
maintenance -- reactive filtering predictive routing
Awareness No knowledge of participants Router needs to know about
required. Adding or removing participants. Router updated if
participants is easy participants are added or removed.
Security Trusted Recipients Don’t Trust Recipients
Traffic High Lower
Applications Generally more efficient with publish- Generally more efficient with queue-based
subscribe channels. channels.
Often used for event notifications / Often used for business transactions, e.g.
informational messages. orders.
14
Multiple but not all Destinations
• A Function can be performed by one or more providers.
• A contract with multiple credit agencies to assess the credit worthiness of
customers.
• If a customer places a large order, we may want to route the credit request
message to multiple agencies and compare the results before deciding.
• The list of recipients depends on the dollar value of the order.

15
Recipient List
Routing
• Define a channel for each recipient.
• Inspect an incoming message.
• Determine the list of desired recipients.
• Forward the message to all channels associated with the
recipients in the list.

16
Recipient List Routing (Computing List)

• Robustness
• Single transaction: commit the messages when all messages are received.
• Persistent recipient list: remembers who received a message.
• Idempotent receivers: safely receive the same message multiple times.

17
Dynamic Routing
• What happen if I need to add a receiver to the recipient list.
• Embed a new rule on the fly to the content-based router without
restarting it.
• Router that can self-configure based on special configuration
messages from participating destinations
• Rule Base Initialization
• Rules Persistency
• Rules Conflict
• Rule Cancellation

18
Dynamic
Routing
• Control channel.
• Allow subscribing and unsubscribing.
• Resolving conflicts
• Ignore conflicting messages (conflict-
free routing table)
• Send message to the first that match.
• Send message to all in interest.

19
Dynamic Recipient List

20
Multiple Section Messages
• The order placed by a customer consists of more than just a single
line item.
• The user though places an aggregate order, not each item separately.
• Hence, we need to find an approach to process a complete order but treat
each order item contained in the order individually.
• A solution should be as generic as possible
• Any number of items.
• New types of added item.
• Receivers act → traffic ??

21
Splitter

• Consumes one message containing a list of repeating elements,


each of which can be processed individually.
• Publishes one message for each single element (or a subset of
elements) from the original message.

22
Splitter

23
Splitter

Static Splitter
• B2B information exchange.
• Split mega-messages into
individual ones.
• Publish resulting messages
to different channels.
• The number of resulting
messages is fixed, hence
static

24
Post Processing of Individual Items
• In most of order scenarios, the further processing depends on
successful processing of the sub-messages.
• If all the items are processed, an overall invoice should be sent to the
client
• If there is a bidding application and customers have placed their
bids.
• we want to select the best bid from several vendor responses.

25
Aggregator

• Collect and store individual messages until a complete set of


related messages has been received.
• Then, the Aggregator publishes a single message distilled from the
individual messages.
• Asynchronous guarantee, messages do not arrive in order.

26
Aggregator

• Stateful:
• The aggregator must remember and store messages needed to form the aggregate
message.
• Completeness:
• When to know that the set is complete? Timeout ? Messages have the information? First
best bid ? External event?
• Correlation:
• How to know a message is related to which set ? Sequence number? Order number?
Bidding item id?
• The Aggregate message:
• Concat ? Summary ?
27
Self Starting
Aggregator

Initialized Aggregator
28
Ordering Messages
• Individual messages may follow different routes, some messages
are likely to pass through the processing steps sooner than others,
resulting in the messages getting out of order.
• Subsequent processing steps do require in-sequence processing
of messages to maintain referential integrity.

29
Re-sequencer

• Receive a stream of messages that may not arrive in order.


• Maintain an internal buffer to put messages in place.
• The in-sequence messages are then published to the output
channel.
• Output channel is order-preserving.
30
Re-sequencer

• Then what happens if the buffer is overrun ??

31
Re-sequencer Only allow a number of messages equal to
the buffer size to be produced (back pressure)

Re-sequencer

32
Routing till
now …

33
Complete Order-Checking
• Maintain the overall message flow when processing a message
consisting of multiple elements, each of which may require
different processing.
• Processes an incoming order consisting of individual line items.
• Each line item requires an inventory check with the respective inventory
system.
• Pass the validated order message to the next processing step.

34
Composed Message Processor

35
Finding Best Bid
• Each order item that is not currently in stock could be supplied by
one of multiple external suppliers.
• Suppliers may or may not have the respective item in stock
• They charge a different price and may be able to supply the part by a
different date.
• To fill the order in the best way possible, we should request quotes
from all suppliers and decide which one provides us with the best
term for the requested item.

36
Scatter and Gather

Distribution via a
Recipient List
Summarization via
Aggregator

37
Combining Both to Complete an Order

38
Sequence of Processing Steps is known at
Runtime
• Route a message not just to a single component, but through a
series of components.
• Validations implemented as a separate filters.
• Each filter inspects the incoming messages, and applies the
business rule(s) to the message.

39
Sequence of Processing Steps is known at
Runtime
1. Efficient message flow - Messages should only flow through
the required steps and avoid unnecessary components.
2. Efficient use of resources - The solution should not use a huge
amount of channels, routers and other resources.
3. Flexible - The route that individual messages that should be
easy to change.
4. Simple to maintain - If a new type of message needs to be
supported, we would like to have a single point of maintenance
to avoid introducing errors.

40
Routing Slip
Efficient flow
Efficient use
Flexible

41
After the validation

Routing Slip step not before

XSimple to maintain (Central edit)


X Efficient use of channels

42
Routing Slip

Combining E and C

43
Routing Slip

44
Parallel Runtime-known Processes
• Routing decisions might have to be made based on intermediate
results.
• The processing steps may not be sequential, but multiple steps
might be executed in parallel.

45
Process Managers
• Use a central processing unit, to maintain the state of the sequence
and determine the next processing step based on intermediate
results.
• hub-and-spoke pattern

46
Process Manages Instances and States

47
Router Pattern Problem it solves

Content Based How do we implement a single logical function that is spread across multiple physical systems?

Message Filter How can a component avoid receiving uninteresting messages?

Dynamic How can you avoid the dependency of the router on all possible destinations while maintaining its efficiency?

Recipients List How do we route a message to a list of dynamically specified recipients?

Splitter How can we process a message if it contains multiple elements, each have to be processed in a different way?

Aggregator How do we combine the results of individual, but related messages so that they can be processed as a whole?

Resequencer How can we get a stream of related but out-of-sequence messages back into the correct order?

Composed Message How you maintain the overall message flow when processing a message consisting of multiple elements, each of
Processor which may require different processing?

Scatter-Gather How do you maintain the overall message flow when a message needs to be sent to multiple
recipients, each of which may send a reply?

Routing Slip How do we route a message consecutively through a series of processing steps when the
sequence of steps is not known at design-time and may vary for each message?

Process Manager How do we route a message through multiple processing steps when the required steps may
not be known at design-time and may not be sequential? 48
UML VS Integration Patterns

• Design an order processing system


that has the shown UML activity
diagram

49
50
Channels √
Basic
Components Routers √
of Pipes and
Filters Translators
Architecture
Endpoints
51
Translators
• Recall our basic objective of integrating different applications or
services altogether.
• Those services may be legacy systems.
• Purchased proprietary solutions that cannot be modified.
• i.e. require decoupling of senders and receivers yet ensuring they
can communicate together.

52
Recall: Channels
• Simply drives the messages from one destination to the other.
• Static paths between applications.
• Does not change the message.

53
Recall: Routers
• Drives the messages along dynamic paths.
• Paths can be predetermined or determined at run time.
• Messages can be divided or aggregated or tagged with their path
(Routing slip)

54
Translators
• Most messaging systems divide the message data into a header
and a body.
• The header contains fields that are used by the messaging
infrastructure to manage the flow of messages.
• Most endpoint systems that participate in the integration solution
generally are not aware of these data elements.
• Endpoint systems rarely agree on the same data format.

55
Translators Envelope
wrapper
Content
Enricher
Translators Content
Filter
Claim
check

Normalizer

56
Envelope Wrapper
We need:
• Existing systems to seamlessly participate in a messaging
exchange that places specific requirements on the message
format, such as message header fields or encryption.
• Example: Dealing with raw messages that should comply with authorized
access rules and data encryption.
• Example: large enterprises using more than one messaging system, they
must bridge the gap between the requirements of different messaging
systems.
• The messages are ENCAPSULATED or WRAPPED in new
complying message.

57
Envelope Wrapper

1. Source publishes data in raw format

58
Envelope Wrapper

2. The Wrapper transforms it into a message format that complies


with the messaging system; adding message header fields,
encrypting the message, adding security credentials.
59
Envelope Wrapper

3
3. The Messaging System processes the compliant messages.
60
Envelope Wrapper

4. The unwrapper reverses any modifications the wrapper made


61
Envelope Wrapper

5. Back to the recipient


62
Chaining Wrappers
• The message get
encapsulated in a
bigger envelope each
time.

63
Envelope Wrapper: The Postal System

64
Content Enricher
What happens if we need to
• Communicate with another system if the message originator does
not have all the required data items available??
• Example: one system may provide us with a customer ID, but the
receiving system requires the customer's name and address.

65
Example: Doctor’s Visit
• Solution A
• It requires a modification to the
scheduling system's internal
structure.
• Overhead of replication.
• If the scheduling system is
customizable, imagine we need to
mail the patient, we will add
mailing functionality and so on…
RECALL: Decouple !!!

66
Example: Doctor’s Visit
• Solution B: The semantics of the
message is more similar to 'Notify
Insurance' than 'Doctor Visit’.
• One system to instruct the next one
on what to do.
• The scheduling system now needs to
know where to get the missing data.
• This ties the scheduling system to
both the accounting system and the
customer care system.
• RECALL: Decouple !!!

67
Example: Doctor’s Visit
• Option C: Decouples the
scheduling system nicely from the
subsequent flow of the message.
• Requires a customizable customer
care system.
• Customer care system indirectly
responsible for sending bills
messages, what if we need other
data?

68
Example: Doctor’s Visit
• Option D: Accounting system
retrieve data.
• Accounting system couple with the
customer care system
• Accounting system Customizable.

69
Content Enricher

• Access an external data source to augment a message with missing


information
70
Content Enricher
• The Enricher
completes the
message.

71
Content Enricher

• Computation: Compute the missing


information. E.g. a state code from
ZIP code.
• Environment: Retrieve the additional
data from the operating environment.
E.g. timestamp.
• Another System: Communicating
with data resources to fill-in needed
data.

72
Content Filter
We need to
• Simplify dealing with a large message, when you are interested
only in a few data items
• Example: A requestor of data may not be authorized to see all data
elements that a message contains.
• Example: Simplify message handling and to reduce network traffic.

73
Content Filter

• Remove unimportant data items from a message leaving only


important items.
• Simplify the structure of the message.

74
Content Filter

• Remove unimportant data items from a message leaving only


important items.
• Simplify the structure of the message.

75
Claim Check
We need to
• Reduce the data volume of message sent across the system
without sacrificing information content.
• E.g. a message may contain a set of data items that may be needed later
in the message flow, but that are not necessary for all intermediate
processing steps.
• A simple Content Filter helps us reduce data volume but does no
guarantee that we can restore the message content later on.

76
Claim Check

• Store data in a persistent store and pass a Claim Check to following components.
• These components can use the Claim Check to retrieve the stored information.
77
Claim Check

1. A message with data arrives.

78
• A business key, e.g. a Customer ID.
Claim Check • Message ID
• Generate a unique ID.

2.a

2. a. The "Check Luggage" component generates a unique key for the


information. This key will be used later as the Claim Check
79
Claim Check

2.b

2. b. The Check Luggage component extracts the data from the message
and stores it in a persistent store, e.g. a file or a database. It
associates the stored data with the key . 80
Claim Check
2.c

2. c. "Check Luggage" removes the persisted data from the message and
adds the Claim Check.
81
Claim Check
3

3. Another component can use a Content Enricher Check. to retrieve the


data based on the Claim
82
Claim Check
3

• Data store implementation: Database? File collection?


• When to delete data?
83
Using a Claim Check to Hide Information
• Remove sensitive data
before sending a message
to an outside party.
• 'need to know basis'.

84
Normalizer
• In an integrated system, where we get the ‘same’ data from
multiple sources, we need to
• process messages that are semantically equivalent but arrive in a
different format.
• Example: business-to-business (B2B) integration scenario.
• Example: General Motors would like to receive order status updates from
their suppliers in a common message format.

85
Normalizer

• Route each message type through a custom Message Translator


so that the resulting messages match a common format.

86
Normalizer

• Uses a Message Router to route the incoming message to the


correct Message Translator .
• Message router should be able to detect the type of the incoming
message.

87
Translator Pattern Problem it solves
Envelope Wrapper How can existing systems participate in a messaging exchange that places
specific requirements on the message format, such as message header
fields or encryption?
Content Enricher How do we communicate with another system if the message originator
does not have all the required data items available?
Content Filter How do you simplify dealing with a large message, when you are interested
only in a few data items?
Claim Check How can we reduce the data volume of message sent across the system
without sacrificing information content?
Normalizer How do you process messages that are semantically equivalent, but arrive
in a different format?

88
How do you make applications conform to the
common format?

1. Change the applications internal data format.

2. Implement a Messaging Mapper inside the application.


3. Use an external Message Translator . You can use an external
Message Translator to translate from the app-specific message
format into the format specified by the Canonical Data Model.

89
Canonical Data Model

• Design a Canonical Data Model that is independent from any


specific application.
• Require each application to produce and consume messages in
this common format.

90
Channels √
Basic
Components Routers √
of Pipes and
Filters Translators √
Architecture
Endpoints
91
Endpoints
• An application does not have some built-in capability to interface
with a messaging system.
• It must contain a layer of code that knows both how the
application works and how the messaging system works, bridging
the two so that they work together.
• This bridge code is a set of coordinated Message Endpoints that
enable the application to send and receive messages.

92
Consumer Patterns
• The consumer patterns of endpoint are not limited to the following
patterns:
• Polling Consumer
• Event-Driven Consumer
• Competing Consumers
• Durable Subscriber
• Idempotent Receiver
• Service Activator

93
Polling Consumer
We need to:
• Consume a message when the application is ready.
• The messages represent work that needs to be done, so the consumer
needs to consume those messages and do the work.
• How to know there are more messages to consume?
• Repeatedly check the channel to see if a message is available.

94
Polling Consumer

• Use Polling Consumer, one that


explicitly makes a call when it
wants to receive a message.
• Synchronous receiver

95
Event-Driven Consumer
• We need to:
• Automatically consume messages as they become available,
Polling enables the client to control the rate of consumption, but
wastes resources when there’s nothing to consume.

96
Event-Driven Consumer

• Automatically hand messages as


they’re delivered on the channel.
• Receiver acts like the message
delivery is an event that triggers
the receiver into action
97
Competing Consumers
• We need to:
• Process multiple messages concurrently.
• Example: when backlog of messages is formed due to a network or a
receiver outage.
• Bounded and bottlenecked by how long does it take to consume a
message.

98
Competing Consumers
• Create multiple Competing
Consumers on a single channel
so that the consumers can
process multiple messages
concurrently.
• Works with Point-to-Point
Channels; multiple consumers
on a Publish-Subscribe
Channel just create more
copies of each message.

99
Competing Consumers

• Transactional controls
ensure that only one of the
consumers successfully
receives the message.
• How quickly the channel
can feed messages to the
consumers.

100
Durable Subscriber
• We need to
• Avoid missing messages while the consumer not listening for
them.
• The consumer went offline for some time.
• The consumer subscribed to the channel after the messages of interest
arrived.
• Practically, to unsubscribe; the subscriber just closes its
connection.
• What if it reconnects? Snooze and lose ?

101
Durable Subscriber

• Make the messaging system save


messages published while the
subscriber is disconnected.

102
Durable Subscriber

• What would happen if a durable


subscriber never unsubscribed?
• The inactive durable subscription would
continue to retain messages until the
subscriber reconnects. Choose
Expiration time ?
103
Idempotent Receiver
• We need
• The message receiver to deal with duplicate messages.
• message delivery can generally only be guaranteed by resending the
message until an acknowledgment is returned from the recipient.
• Example: ack gets lost.
• Example: failed distributed transaction
• Guaranteed delivery is not always available (unreliable
connections)

104
Idempotent Receiver
• Explicit "de-duping", i.e. the
removal of duplicate
messages.
OR
• Defining the message
semantics to support
idempotency.
• Persistence of the received
IDs.

105
Service Activator
• An application has a service that it would like to make available to
other applications.
• How to design such a service to be invoked both via various
messaging technologies and via non-messaging techniques.
• Support Synchronous and asynchronous execution.

106
Service Activator
• Service Activator that connects
the messages on the channel to
the service being accessed.
• Service Activator can be one-way
(request only) or two-way
(Request-Reply ).
• hard-coded/ reflection.

107
Service Activator
• A Service Activator enables a
service to be written as though it’s
always going to be invoked
synchronously.

108
Receive Endpoint Problem it solves
Pattern
Polling Consumer How can an application consume a message when the
application is ready?
Event-Driven How can an application automatically consume messages as
Consumer they become available?
Competing How can a messaging client process multiple messages
Consumers concurrently?
Durable How can a subscriber avoid missing messages while it’s not
Subscriber listening for them?
Idempotent How can a message receiver deal with duplicate messages?
Receiver
Service Activator How can an application design a service to be invoked both via
various messaging technologies and via non-messaging
techniques? 109
References
• Chapter 7,8,10 “Enterprise
Integration Patterns”.

110

You might also like