Presentation from WJAX 2015 with Oliver Gierke. Compares REST and Messaging as an integration approach for Microservices.

1. REST VS. MessagingIntegration Approaches for Microservices
Eberhard Wolff
/ ewolff / olivergierke
Oliver Gierke

2. Microservices
2
ECommerce
Order Customer
Delivery
Order Customer
Delivery
Package WAR

3. Integration
3
UI
Logic
Data
Links Modular UI
REST Messaging
Replication
No Common
Schema!

4. Overview
4

5. REST
• Architectural style
• Constraints in architecture result in
traits of the system
• Identifiable resources, uniform
interface, representations,
hypermedia
• Synchronous by default
5
?
Microservice
Microservice

6. REST
• Service discovery
• DNS or registry & hypermedia
• Load balancing
• Dedicated infrastructure
• So!ware load-balancer (Ribbon)
6
?
Microservice
Microservice

7. Messaging
• Microservices send message
• Asynchronously
7
Microservice
Microservice

8. Load Balancing
• Can have any numbers of
instances of a receiver
• Load Balancing very easy
8
Microservice
MicroserviceMicroserviceMicroservice

9. Service Discovery
• Microservices send
messages to queues / topics
• Receiver(s) read messages
• Decoupled by queues &
messages
• No need for service
discovery
9
Microservice
MicroserviceMicroserviceMicroservice

10. Fire & Forget
10

11. Example
11
Order
Payment
Credit card booking
200€

12. REST
• F&F doesn’t fit naturally
• Which HTTP method to use?
• Requests to create side
effects
• DELETE, PUT, POST
12
?
Microservice
Microservice

13. Safety / Idempotency
13
HTTP Method Safe Itempotent
GET
PUT
DELETE
POST
PATCH

14. REST: Failure
• Remote system unavailable
• Can’t easily retry because
of non-itempotency
• Status codes to
communicating semantic
problems
14
?
Microservice
Microservice

15. Messaging
• Hand message over to
messaging system
• Messaging system
guarantees delivery
• Stores message
• Acknowledgement
• Might have duplicated messages
15
Microservice
Microservice

16. Messaging: Failures
• Message doesn’t make it into
the message broker
• e.g. Timeout / TCP problem
• Retry
• Rely on re-transmission of
incoming message
16
Microservice
Microservice

17. Request & Reply
17

18. Example
18
Order
Payment
Validate credit card # OK / not OK

19. REST
• Natural model
• GET request
• Support for caching built in
• ETags, Last-Modified,
conditional GET / PUT
• Still needs care
• Timeouts, resilience
19
?
Microservice
Microservice

20. Messaging
• Send request
• Expect response
• Correlation
• …or temporary queue
• Asynchronous by design
20
Microservice
Microservice

21. Resilience
• Messaging can guarantee
delivery
• Failure just increases latency
• System must deal with
latency anyway
21
Microservice
Microservice

22. Events
22

23. Event Driven Architecture
• Order sends events
• Decoupled: no call but events
• Receiver handle events as
they please
23
Order
New Order
Event
Payment:
Books credit card
Delivery:
Ship products

24. Event Driven Architecture
• System are built around publishing domain events
• Multiple event listeners
• Event listener decides what to do
• Can easily add new event listener with additional business logic
• Challenges
• Delivery hard to guarantee
• What about old events?
24

25. Events + REST = Feed
• System stores domain events and publishes feed (e.g. Atom)
• Strong consistency within the service
• No additional infrastructure required
• Getting closer to Event Sourcing
• Clients subscribe to feed
• Clients in charge of polling frequency
• Server side optimizations: caching, ETags, pagination, links
• Client side optimizations: conditional requests
25

26. Messaging
• Publish / Subscribe e.g. JMS Topics
• History of events limited
• Guaranteed delivery somewhat harder
26

27. More Decoupling
• Enterprise Integration
Patterns (Hohpe, Woolf)
• www.eaipatterns.com
• Contains patterns like
Router, Translator or Adapter
• Create flexible messaging
architectures
27

28. Code
28
@Inject OrderRepository repository;
@Transactional
public void order(Order order) {
repository.save(order.deliver());
doCreditCardBooking(order.getCcNumber());
}

29. Transactions
29

30. Messaging & Transactions (Commit)
• Database commit
• Incoming messages
acknowledged
• Commit success: outgoing
messages sent
• Outgoing messages hopefully
handled successfully.
• Inconsistencies: Outgoing
messages not yet processed
30
Microservice

31. Microservice
Messaging & Transactions (Rollback)
• Database rollback
• Outgoing message not sent
• Incoming message
retransmitted
31

32. REST & Transactions
• No implicit infrastructure support
• But can be built manually
32

33. REST & Transactions
33
@Inject OrderRepository repository;
@Inject ApplicationEventPublisher publisher;
@Transactional
public void order(Order order) {
repository.save(order.deliver());
publisher.publish(new OrderDeliveredEvent(order));
}
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onOrder(Order order) {
doCreditCardBooking(order.getCcNumber());
}

34. Evolvability
34

35. Evolvability
• Core aspect of Microservices: independent deployability
• Means: decoupling
• Change in one system must not break downstream systems
35

36. REST
• Core concepts built into the protocol
• Representations
• Content negotiation
• Media types
• Hypermedia
• Discoverability
36

37. Messaging
• Data format: Your choice
• i.e. easy to evolve if changes backwards-compatible
• But: no support for content negotation
37

38. Summary
38
REST Messaging
Communication style synchronous asynchronous
Service Discovery
DNS, Service Registry
Resource Discovery
Message Broker
Queues / Topics
Strengths
Content negotiation, Hypermedia
More control over direct interaction
Messages in
Re-submission of messages

39. Your next project:
Messaging or
REST?
39

40. You’ll probably
use both :-)
40