Windows Azure AppFabric Service Bus Future – PDC10 Session Review
Clemens Vasters – Principal Technical Lead @ Windows Azure Team
Service Bus Today
- Naming fabric or Structure that sits out on the internet that provides us to create a namespace
- When we create a namespace for the service bus, Microsoft provisions a tenant in a multi-tenant value fabric for us, where we can create endpoints, message buffers, and communicate through those.
- Around this routing fabric we have several nodes where we connect and that’s is where the fabric is being used.
- Use Case Samples:
- Message Queues: Wherever you need some application queue
- Airline that is using this to check-in and synchronize devices using this
- Outside Services: Whenever you need to provide a public facing service, but your internal service
- MultiCast (Eventing)
- Direct Connect (Bridge two environments through Firewalls and NAT.
- Message Queues: Wherever you need some application queue
A look into the Future
- Service Bus Capability Scope
- Connectivity (currently in the CTP)
- Service Relay
- Protocol Tunnel
- Eventing
- Push
- Messaging (currently in the CTP)
- Queuing
- Pub/Sub
- Reliable Transfer
- Service Management
- Naming
- Discovery
- Monitoring
- Orchestration (Workflow)
- Routing
- Coordination
- Transformation
- Connectivity (currently in the CTP)
- Service Bus October 2010 Labs (labs release not parity with production services)
- New and Improved
- Load Balancing
- I need to be able to take multiple listeners and host them on Service Bus and have load balancing on them
- This is not possible on the production environment, and in the Labs we have a new protocol called AnyCast to provide this.
- Richer Management
- Durable Message Buffers
- We want to be more queues and less about message buffers
- Load Balancing
- In this October 2010 Labs Release we don’t have:
- HttpListeners
- Capabilities in the Service Registry
- Missing some composition capabilities
- Missing all the bindings
- The purpose is to gather feedback about this new protocol
- New and Improved
- Durable Message Buffers
Version | Storage | TTL | Capacity | Messages |
Production | In-Memory | 10 mins | 2 MB | 60KB |
Labs | Durable and Replicated Storage | No Limit | 100 MB | 256KB |
- Same Lightweight REST protocol
- Long pooling support
- Future Releases
- Reliable Transfer protocol options
- Higher throughput transport options
- Volatile buffers for higher throughput
- Currently the same protocol backed up with a REAL Queuing system that is reliable and capacity.
- Listener Load Balancing
- Connection point management separate from listener
- Explicit Management of service bus connection points to the service bus
- We gain the ability to know if someone is listening or not.
- Multiple listeners can share the same connection point
- Load balancing and no single point of failure
- Sticky sessions
- Connection point management separate from listener
- Session Multiplexing
- One socket per listener
- Optimized for short sessions, and short messages
- The latency for setting up that session is now very short
- No extra round-trip to set up a session
- Note: The purpose is to reduce latency
- Explicit Streaming Support (Default model in production Today)
- One socket per client
- Optimized for long sessions, streaming and very large messages
- Lightweight handshake, mostly ‘naked’ end-to-end socket afterwards
- Note: This will be made available later into the Labs
- Namespace and Management
- Management Surface Today
- Implicit for connectivity
- Connection points created on-the-fly
- Explicit for message buffers
- Atom Publishing Protocol
- .servicebus.windows.net">.servicebus.windows.net">.servicebus.windows.net">.servicebus.windows.net">.servicebus.windows.net">https://<tenant>.servicebus.windows.net
- Runtime artifacts (listeners, message buffers) share address space with management
- Implicit for connectivity
- Refactoring Goals
- Management consistently explicit
- No more implicit connection points, just explicit
- Split management and runtime surface
- Enable richer addressing/organization
- Management consistently explicit
- In the Labs
- Namespace is split into 3 different views
- Runtime (Organized by Concerns)
- Observation & Discovery (Organized as mirror of runtime view)
- Management (Organized by Resource and Taxonomies) – Currently not available
- Management operations are now explicit only
- Management store is persistent. No renewals
- Atom Publishing Protocol / REST
- Uses OData protocol behind the scenes
- New url will be:
- Each of the artifacts has a mapping into the runtime namespace (this is the url we know today .servibus.windows.net/">.servibus.windows.net/">.servibus.windows.net/">.servibus.windows.net/">.servibus.windows.net/">https://<namespace>.servibus.windows.net/.
- Namespace is split into 3 different views
- Management Surface Today
- Protocols
- Currently allowed
- NMF (net.tcp)
- Http(S)
- Currently thought
- FTP
- SMTP
- SMS
- Other
- Candidate Example of those: XMPP, … (not planned but thought as possible candidates)
- Currently allowed
- Messaging
- Reliable, transacted, end-to-end message, transfer of message sequences
- Local Transactions
- Batches are transferred completely or not at all
- Service Bus Pub/Sub – Topics
- Service Bus Topics
- Think of as a message log with multiple subscriptions
- Durable message sequences for multiple readers with per-subscription cursors
- Pull Model consumption using messaging protocols
- Service Bus manages subscription state
- Service Bus Topics
- Service Bus Pub/Sub – Eventing
- Service Bus Events
- We already have it with neteventrelaybinding
- Multicast event distribution
- Push delivery via outbound push or connectivity listeners
- Same subscription and filter model as topics
- Considering UDP for (potentially lossy) ultra-low latency delivery
- Service Bus Events
- Service Bus Push Notifications
- Distribution points allow for push delivery to a variety of targets
- Built on top of pub/sub topic infrastructure
- Protocol adapters for HTTP, NET/TCP, SMS, SMTP, …
- Subscription-level AuthN and reference headers
- Monitoring
- Monitor of Service Bus state
- System events exposed as topics with pull and push delivery
- Events can flow into store for analytics
- Ad-Hoc queries into existing resources and their state
- Discovery
- Discovery of Service Bus resources and resource instances
- Eventing and query mechanisms similar to monitoring
- Service Presence
- Custom Taxonomies
What can you do know. Use AppFabric Service Bus Labs
- http://portal.appfabriclabs.com
- Register for a Labs account
- Download the SDK
- Try things out