In startups and SMBs an Application Bus architecture is usually cheeper and sufficient to meet the need, but they always lack the features and scale of a true ESB. For larger clients, a framework solution, like Biztalk, usually takes the lead. In this case the frameworks are so cumbersome that they violate many of the rules of loosely coupled architecture. Either way, these solutions make my inner geek toss and turn with nightmares of technical debt and unneccessary overhead.
Finally this long awaited dream solution has become a reality; thanks to Window's Azure AppFabric. The AppFabric encompasses many of the components we would want in an ESB, giving us the control and features of a traditional ESB. The biggest difference is that Microsoft has moved this particular ESB to the internet and accepted the task of overseeing its maintenance. The AppFabric offers the features of an ESB without all the garbage found in a full framework solution.
After a year of development and feature enhancement, the AppFabric team has completed the first complete developer's guide to the AppFabric. Now its easy to learn how take advantage of its features without having to spend weeks of experimentation or months/years of trying to roll your own. But before you run out and start implementing the AppFabric, take a moment and read about what an ESB is and what's in the AppFabric ESB.
What's an Enterprise Service Bus?
In enterprise architecture, an Enterprise Service Bus (or ESB) is quite literally like a bus. It carries bits of data or service calls from one service to another or one application to another. When implemented properly it simplifies the management of security, communication, and maintenance of loosely coupled services.
In the context of cloud based solutions, an ESB bridges the gap between components of the service running in the cloud and on-premise applications through the creation of a facade in the service bus.
What's in the AppFabric?
While still a relatively new offering from Microsoft, the AppFabric already contains many of the features required in an effective Enterprise Service Bus. In its current version it includes the following: Access Control, Messaging, Message Buffers, and Naming/Discovery. Overtime, I'm sure it will adopt even more ESB features.
Naming/Discovery:
AppFabric, uses a URI based naming system for the management of service names. In this system the owner of the service sets names for each unique endpoint within their namespace as follows: [scheme]://[service-namespace].servicebus.windows.net/[name1]/[name2]/...
These services are registered on the Service bus and all public services can be discovered via an atom feed for each namespace.
Messaging:
The centerpiece of any good ESB is found in its messaging management. Of any I've worked with in the past, AppFabric is by far the most advanced. Most of the features of an ESBs messaging platform are found in the way you bind to services. Unlike custom built ESBs or the typical vendor driven ESB, the Bindings in AppFabric contains both vendor specific and vendor agnostic approaches ranging from the Basic Http Binding to ever coveted Net TCP Relay binding.
In Net TCP Relay Binding, the client who calls a service sends and initial message to the service bus. The service bus then negotiates NAT traversal for the client and the service to attempt to connect the two directly. This upgrade process eliminates overhead when calling services by bipassing the service bus altogether. In this sense, the service bus achieves the highest objective of any ESB, provide service management and facilitation without interfering with service execution.
Access Control:
The biggest challenge in the technology portfolio of many organizations is the creation of the single sign on process. How do we give our customers/employees one user name and password that traverses multiple applications and services. Accomplishing this can sometimes be more difficult than the development of the application itself. Fortunately, any good ESB, AppFabric included can tackle this challenge for you.
Gone are the days of Kerberos or the antiquated AD query language. In AppFabric, Microsoft went a different route and built in an open standard for authentication and authorization based on the OAuth standard. Best of all, they included the tools for integrating with Active Directory, Windows Live, Yahoo Id's, and a number of other non-Microsoft issuers. This means that it can work with most any form of centralized authentication.
Message Buffering:
Message buffering does just what its name suggests, it buffers messages from the client to the service. This allows for two key features in a SOA solution. First, it makes communication from one app to another easier even if the client is using legacy development tools or non-Microsoft platforms by communicating over a simple http(s) binding even if your app is designed for Net TCP Relay Binding. Second, it buffers messages in a queue allowing for delayed execution of messages up to 5 minutes, thus allowing your internal app to process certain calls at its own pace.
Conclusion:
The Windows Azure AppFabric finally gives .Net developers a convenient way to implement an ESB without the overhead and development cost associated with more complex framework or custom built solutions. Its one more way in which Azure helps cut through the expense of development and get us to the point of delivering business value faster.
To learn more about Windows Azure AppFabric, check out the developer's guide to the AppFabric.
Posts
