1. Service Bus and REST
The Service Bus is designed
to support REST interactions between services and consumers and
provides several REST-based APIs for establishing and managing the
configurations and relationships implemented in the Service Bus.
REST-Based Service Design
Creating a REST-based service to
be projected on Service Bus does not require any special steps beyond
what is normally used to make a service REST-accessible.
For services built using the
AppFabric SDK, only a few WCF-specific changes are required, none of
which are AppFabric-related. Specifically, this entails the addition of a
series of attributes to the contract definition to map to commands in
REST-specific protocols. Subsequently, we need to use WebHttpRelayBinding from the AppFabric SDK.
Services built with access to
the AppFabric SDK can publish their service endpoints on the Service
Bus. However, services built without access to the AppFabric SDK will
need to accomplish this by working with message buffers.
REST-Based Service Consumer Design
Similar
to building services, creating REST-based service consumers that access
the Service Bus does not require any special steps other than
implementing the basic AppFabric Service Bus programming model (which
requires defining and creating a service contract, using a binding and
security credentials to connect to the Service Bus, and so on). For this
purpose we also need to use the WebHttpRelayBinding WCF binding.
As with services, service
consumers built without access to the AppFabric SDK will need to
interact directly with the Service Bus by working with message buffers
(via REST-based APIs).
Message Buffers and REST
Message buffers use the HTTP protocol to expose various operations, such as:
creating a message buffer
sending a message to a message buffer
retrieving a message from a message buffer
expiring and deleting a message buffer
Message buffers’ usage
of the protocol relies on Access Control’s HTTP authorization model to
help enforce access control with the buffer. This means that the Simple
Web Token (SWT) mechanism is used to retrieve tokens with HTTP, and then
embed the tokens in HTTP request headers. These tokens include claims
that are used to determine whether an operation should be allowed.
2. Service Bus Connectivity Models
The Service Bus supports
the following set of diverse connectivity scenarios that are refactored
into three distinct models (also referred to as patterns):
Eventing
Service Remoting
Tunneling
These models can be used to
support commonly used service-oriented messaging and interaction
patterns between participants, regardless of location (on-premise,
public cloud, client devices, etc.).
Eventing
The
Eventing model is based on asynchronous, publish-and-subscribe
communication over non-persistent connections using sessionless unicast
(to one receiver) or multicast (to multiple receivers) datagrams (Figure 1).
The model can be used for:
cloud monitoring– Events from a cloud-based service can be broadcast over the Internet directly to listeners.
monitoring SaaS–
The Service Bus can be an event collection point where notifications
from multiple sources, regardless of location, can be aggregated into a
single stream for cloud-based monitoring tools.
event-driven services composition–
The Service Bus can be used to syndicate and propagate events among
participants which can be distributed systems residing at different
locations on the Internet.
Service Remoting
The
Service Remoting model is generally based on RPC-style or
request-response communication as part of one-to-one data exchanges. It
typically relies on synchronous communication over persistent
connections (which can be shared and reused), but can also support
synchronous-over-asynchronous scenarios over non-persistent connections (Figure 2).
The model can be used for:
service messaging– Fundamental consumer-to-service data exchange based on the request-and-response message pattern.
peer-to-peer applications–
For Internet-enabled device integration, without the need for
specialized local networking capabilities for discovery and access
control.
ad-hoc application groups–
A number of components can rendezvous on the Service Bus and share data
and processes for collaboration and/or integration purposes. This
effectively forms a dedicated virtual private communications environment
for the group.
Tunneling
The Tunneling model is based
on two-way communication that can support full-duplex exchanges. As with
the Service Remoting model, it is typically used for one-to-one
interactions and relies on raw binary streams over dedicated, persistent
connections (Figure 3).
The model can be used for:
port forwarding–
This facilitates specialized protocol dependent communication between
the service and consumer by embedding and tunneling binary streams as
part of service message payloads.
reverse Web proxy–
Here the Service Bus is allowed to become the public service endpoint
for Web servers running behind FW/NAT environments and not needing to
make changes to the physical networking environment.
ad-hoc logical network partitioning–
A number of agents and bridges can rendezvous on the Service Bus to
effectively create a temporal virtual network environment that allows
many-to-many communication among participants attached to the rendezvous
address.
