The BizTalk Labs Internet Service Bus
An Internet Service Bus (ISB) is a set of services that simplifies developing SOA
and Web service applications. The Microsoft ISB combines hosted, network accessible
building block services, with local services and capabilities accessed via APIs
and programming framework extensions.
The ISB building block services are general-purpose and provide foundational capabilties
that are independent of application business logic. These building block services
extend the existing platform capabilities in the .NET Framework, such as the communication
capability provided by
Windows Communication Foundation.
Internet Service Bus Building Block Services
The BizTalk Labs ISB provides three building block services:
These building block services do not deliver disjoint, independent capabilties.
Rather, the ISB is an integrated whole. The most interesting application scenarios
will employ a combination of these services. Despite this, projects can consume
elements of the ISB without understanding the whole.
The Internet Service Bus combines the technologies and standards that make the Web
work today - HTTP, URI's, RSS, and Atom - with technologies from the enterprise
such as SOAP and WS-Trust. Applications of all types can connect to the ISB - from
basic Web browsers to advanced desktop applications or server agents. Client applications
to take advantage of rich client capabilities when possible without sacrificing
the broad reach of the Web. Combining the best technologies from the enterprise
with the ubiquitous technologies from the Web, the ISB enables rich scenarios like
publish/subscribe eventing and federated security at Internet scale.
The BizTalk Services Software Development Kit
In addition to the Building Block services, the ISB offering from Microsoft includes
a downloadable Software Development Kit (SDK) that
provides extensions to the existing .NET Framework, to simplify the process of creating
new, composite applications. The SDK provides a new WCF channel, which can enable
many existing .NET applications to use the ISB hosted services without changing
any code.
Because the SDK appears as a set of extensions to the existing .NET Framework, developers
with .NET Framework skills and tools can immediately be productive using the ISB
hosted services.
The programming framework extensions delivered by the SDK can be used for many networked
applications, whether they connect to the hosted services of the Microsoft ISB or
not.
Where's the Bus?
Commonly, depictions or descriptions of service buses seem to imply that the bus
is a free-standing entity with a definite location. This is an unnecessarily limited
perspective. In fact, we should consider the ISB to be a ubiquitous fabric
that enables connections between and among services: between multiple services running
on the same local network, between and among services that span multiple enterprises,
or even between two services residing in the same computer system.
According to the traditional perspective, you might think of the set of hosted building
block services as comprising the Microsoft ISB, while the SDK provides a set of
frameworks and code for simplifying interaction with the ISB. This is a familiar
and intuitive model, and is not far off the mark. But in fact, the ISB is delivered
by the combination of these things, and the ISB is constituted by both local framework
library code as well as the remote services.
The hosted services and the framework extensions in the SDK will often be used together,
but can be used independently.
- The framework extensions in the SDK provide value in scenarios that do not connect
to the hosted building block services.
- The hosted building block services in the ISB will be accessible without relying
on the SDK, via standard Web service and web protocol connections, which enables
connection with Java, PHP, and other web-enabled platforms and languages.
Identity
The Identity Service is a publicly-accessible, Web service callable
Security Token Service (STS). Third-party websites and applications can
use the Identity Service for authentication and access control of other users and
applications.
User applications connect to the Identity Service to obtain secure authentication
tokens. These tokens can then be exchanged between applications, to allow the communicating
parties to provide proof of their identities. Of course, the communicating applications
may reside in different enterprises or organizations.
The Identity Service also supports authorization or access control on communication
endpoints managed by the Connectivity Service. In the simplest case, one application
can send messages to an endpoint, while another application can listen for messages
arriving on that endpoint. Via the Identity Service, developers can specify, via
Web service APIs or a Web UI, which identities can send or listen on any endpoint.
The authorization model includes groups, authorization policies and supported authentication
and security providers.
The programming framework extensions provided in the SDK enable applications to
authenticate with STS, receive and manage security tokens, and propagate tokens
on WCF communication channels.
Connectivity
The Connectivity Service supports application-to-application communication, across
organizational and network boundaries. Sending outbound messages from within a corporate
network is often easy, but network firewalls typically restrict inbound messages.
Under this model, messages can be sent but never received. The BizTalk Services
Connectivity Service addresses this obstacle.
Applications that exploit the Connectivity Service, regardless whether they are
sending or receiving messages, establish outbound connections to the Connectivity
service; these outbound connections are permitted by typical network firewall configurations.
Each set of applications can intercommunicate by specifying the same URI for the
communication endpoint.
When an application listens on an endpoint, it automatically polls the
Connectivity Service to retrieve incoming messages. In a simple example, suppose
applications in two distinct enterprises send and receive messages through the WCF
framework and APIs. Enterprise A establishes an outbound connection to the Connectivity
Service, and begins listening on an endpoint, defined by the URI labs.biztalk.net/enterpriseA/someapp. Enterprise B also establishes
an outbound connection to the Connectivity Service, and sends a message to the same
URI.
The Connectivity Service receives the message, and relays it to the application
in enterprise A, via its already open connection. The SDK simplifies developing
applications that use the ISB online services, and enables existing applications
to use the ISB without modifications.
The Connectivity Service expands the basic message relay capability, also providing:
- Multicast: Enterprises A may send messages to enterprises B and C by sending a message
to a single URI to which enterprises B and C connect.
- Protocol Adaptation or Bridging: Over time, the ISB will support an increasing set
of protocols for connectivity. A simple example might be enterprises A sending a
message using the SDK. Enterprise B may retrieve the messages through Web service
standard protocols and enterprise C may retrieve the message by subscribing to a
feed.
- Publish/Subscribe: The ISB supports functions for emitting events, and for subscribing
to selected events at URIs. Over time the functions will be equivalent to WS-Eventing.
The Connectivity Service will support the WS-Eventing standards as well as other
protocols (like feeds) for interacting with the publish/subscribe functions.
Workflow
BizTalk Services will provide the capabilities of a hosted instance of Windows Workflow
Foundation to applications that use the ISB. Workflows, running on the hosted ISB,
will activate based on messages received at URIs the ISB. Workflows provide support
for multistep processing of messages including transformation, sending messages
and receiving responses from connected services (through the Connectivity Service),
etc. Applications and users will be able to define the workflows and associate them
with URIs using simple tools.
Additional Building Block Services
Over time, BizTalk Services will provide additional Building Block Services. Some
examples might include:
- A logging service for logging messages passing through URIs. This might be useful
for logging high value financial messages.
- Storing copies of messages sent and received by workflow processes to simplify recovery
logic at connected applications.
The set of additional building block services will grow over time, based on customer
feedback.
The BizTalk Services hosted services provides a platform for a larger ecosystem
of applications and services ISVs, enterprises, system integrators, and so on, can
attach new building block services to the ISB in the same way that they can attach
business applications, that is, through URIs and the Connectivity Service. A simple
example might be a service that transforms or maps messages between two common but
different industry formats. Multiple enterprises could use this building block service
to simplify integrating their business applications/services. BizTalk Services enables
innovation and extensions by enabling attachment of useful building block services.
Status
The ISB technology is currently available as a Community Technology Preview (CTP).
This is not a beta of a product release; as the CTP moniker suggests, it is a preview
of technology. You can consider the ISB to be am "external technology incubation".
Given this early-stage status, the ISB technology is currently available free of
charge. Microsoft will manage the BizTalk Services infrastructure on a best-efforts
basis. These technologies are not currently intended for use within production-level
applications. The goal over time is to provide a platform that supports production
level, critical applications.
Microsoft will steadily fill out more of the offering, and the status of the various
pieces will change. Stay tuned to this website for full details.
Learning More
Click here to learn more about the business benefits
of an Internet Service Bus.