Monday, August 19, 2013

Service Bus Deep Dive – personal notes


This video is a must see ‘Service Bus Deep Dive’ together with the presentation. Clemens explain all the Service Bus capabilities, which can be used in various scenarios, and most importantly, are being used in various scenarios which he explains as well.


As most of the explanation in his video is also covered in the presentation, I’ve tried to make notes (again: PERSONAL notes), of what I think is something to highlight.

These notes are grouped per main category in the presentation

Service Bus
Service bus will remain available in 2 flavors, the Server and Cloud version. The focus will be on delivering functionality in the Cloud version first, after which bugfixing, takes places and eventually a code merge to the Server version.

- Cloud functionality (released frequently)
- On Premise (released once 1 year – end of the year)

Brokered messaging
- Flow rate is roughly determined (throughput \ # subscriptions)
    - e.g. 2000 throughput
    - subscriptions == number of copies of the message
- Messages are persisted in SQL before the ACK is returned
- MSMQ team is integrated within Azure Service Bus team (will remain supported)

ServiceBus API
- SB Messaging protocol (ports 9354 or 443/80) ==> will be replaced by AMQP (in the future)
- AMQP(S) with (S) being the problably supported method (S: 5671, normal: 5672)
- AMQP vs Relay (idea to extend AMQP with Websockets to migrate SBMP features)
- HTTP(S) does not support transactions/sessions
- Possible implication: AMQP support in BizTalk
- Possible implication: Relay support in BizTalk will change

Message dimensions
- max total props: 64kb (-4kb reserved props)
- max body (256kb) - size of props!

Message protocol mapping:
- http (json) ==> brokered message (automatic mapping)
- AMQP ==> brokered message (automatic mapping)
- SOAP message ==> brokered message (explicit promotion required)

Delivery options:
- Peek Lock (reliable messaging) ==> possible loss of order
- Session + Peek lock (lock all messages, ensuring order)

Receive Operations:
- AMQP/SBMP session/connection is maintained ==> much more efficient
- HTTP single receive operation ==> less efficient

Pricing (1 feb 2013)
- 1 dollar = 1 million msgs
- each chunk of 64kb is considered a transaction!
- Long-polling (HTTP) means a transaction per poll, also charged in case of empty body
- pricing depending on zone (asia is the most expensive)

Messaging / Composite patterns ==> Must see
Correlation recommendation: Session Correlation

Messaging features
- sql subscription actions; can change message properties, can not change message content
- topic pre-filtering:
    - check if there are subscribers
    - slower
    - ack after executing rules
    - when: used to group a set of related activities, for example processing a large file splitted
    into smaller chunks
    - no time limit
    - !state! can be used to work stateless while processing workload (state machine / workflow capabilities) e.g.;
    Clients     Sends processing work
    Consumer     iterates through the sessions (acceptMessageSession)
    Consumer     receives the message (session.Receive())
    Consumer     processing part of the message and updates the state (session.SetState(...))

    Consumer2    Retrieves the state
    - no DTC
    - System.Transactions scoping model
    - Distributed transactions are possible using queues ("via" entity)

    - when: High throughput
    - Usage: in stead of processing per message using the 'Receive' method, processing takes places using a local buffer

Auto forwarding (Queue)
    - Allows decoupling
    - Allows dynamic reconfiguration (switch over based on message properties)

    - Things will fail
    - Exceptions with '.IsTransient' can be retried safely
    - Support requests
    NS Namespace
    TransactionID (from the exception)
    - Everything should be implemented A-Sync for high-throughput
    (later this year available in all API's)



No comments: