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.

image

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
sessions
    - 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
   
Transaction
    - no DTC
    - System.Transactions scoping model
    - Distributed transactions are possible using queues ("via" entity)

Prefetch
    - 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)

Guidance
    - 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)
   

HTH,

Sander

Comments

Post a Comment

Popular posts from this blog

Azure implementation guidelines

In My post ‘ Service Bus Management ’ I pointed out a way of implementing a DTAP strategy for managing the Service Bus environment. There’s now a great post available from Microsoft which goes into more detail about other aspects of managing the Azure subscriptions and other artefacts which is quite useful when setting up your Azure environments. Follow this link to the ‘Azure Implementation Guidelines’ HTH, Sander
Read more

Focus and innovation - recap of the last 2 years

It's been a long time since my last post. Hereby a partial explanation for that, with the note that this blog will remain active for the purpose of being a resource for historical references. My IT career started with programming, and adventures within holland, as well as overseas. When I realised programming is something you can specify, I figured that providing added value is crucial for a long term career and decided to focus on process centric roles. I started with webservice integration and eventually from that to process integration using BizTalk. The great feeling when discussing high level processes and implementing solutions within days, even highly scalable and interfacing with LOB systems is great. After several years of implementing solutions like these, I started questioning if all of this work was justified by the business case, if the solution was actually contributing, if the choices had been valid. In other words, I needed to understand the choices made. When...
Read more

BizTalk Pub/sub vs Topics based routing–discussion

My colleagues and I had a brief discussion about the subject ‘Topics’ and what it brings… Do you all agree/disagree with the following statement: topic-based pub-sub messaging doesn’t really exist in BizTalk “In my opinion; I disagree, as BizTalk offers the following 'out-of-the-box' • Message Routing (f.e build in context properties like message type, trading partner, operation etc) • Content Routing (f.e. promoted properties, message inspection in orchestrations/pipelines icw orchestration logic)” My colleague Rene Brauwers Here my 2 cents…. I agree that it exists...however the current offerings in BizTalk are tightly coupled, making the usage far from perfect. When doing content based routing on custom fields (promoted properties), you will be making the solution message-coupled; Your custom message property schema is deployed, and the message filter on these fields have a direct relationship with this property schema. Making any change to this schema will g...
Read more