In dynamic e-business environments, companies want to respond rapidly and effectively to events rather than be overtaken by them. Forward-looking companies design their distributed services on event-driven principles.
This strategy helps ensure that important events — in applications, systems and components — are communicated in real time to the appropriate parties. Event-notification services let applications specify the types of events they’ll publish and subscribe to, the formats in which notifications will be transmitted, and the frequency with which they’ll be sent.
Until recently, the Web services industry lacked open standards for event notification. Last month, two industry groups released rival specifications that address this requirement. One group — BEA Systems Inc., Microsoft Corp. and Tibco Software Inc. — published a co-authored specification called Web Services Eventing (WS-Eventing); another, led by IBM, released its Web Services Notification (WS-Notification) spec.
One important feature of WS-Eventing and WS-Notification is that they do not restrict the types or contents of messages that might serve as event notifications, nor do they restrict which entities might publish and subscribe to these messages.
This means developers can begin to implement a general-purpose events infrastructure and, as Web services based on Simple Object Application Protocol become ubiquitous, make this infrastructure available to all applications and services.
Notifications of user-generated events should be distributed in the same general-purpose infrastructure that handles system-level notifications. Inevitably, WS-Eventing and/or WS-Notification (or some converged specification that supersedes both) will be implemented in identity management systems to notify applications of important events concerning particular users.
For example, an identity management environment might notify authorized applications that a user has connected to the network, logged on to a particular domain, moved to particular geographic coordinates and been granted particular roles, permissions and personalization settings.
To varying degrees, the flow of identity information is determined by the implementation profiles of identity management federation protocols, such as Security Assertion Markup Language (SAML) 1.1; Liberty Alliance Identity Federation Framework (ID-FF) 1.2 and Identity Web Services Framework (ID-WSF) 1.0; and Web Services Federation Language (WS-Federation) 1.0.
Both Liberty ID-WSF 1.0 and WS-Federation 1.0 define complex infrastructures for brokering requests for identity-related user attributes among federated identity management domains.
However, both specs fall short of defining publish and subscribe (pub/sub) protocols for handling identity information interchange across federated identity management infrastructures.
That’s where WS-Eventing and/or WS-Notification will prove indispensable. They’re part of a broader set of WS-* specs designed to build on one another within the Web services framework.
This means other Web services needn’t embed their own special-purpose eventing infrastructures. Instead, they should have access to a universal event service that implements one of the two specs.
Liberty should reference WS-Eventing and/or WS-Notification in its identity management protocols, and the developers of WS-Federation should do likewise in future revisions. And as OASIS’ Security Services Technical Committee continues development on SAML 2.0, it should begin to consider the need for a general-purpose event pub/sub environment for federated identity management.
However, the SAML 2.0 feature list has more or less been finalized, and event notification isn’t on it. Identity event notification will become a candidate for the eventual SAML 3.0 as soon as the federated identity management industry catches the vision and begins to compose standards with WS-Eventing and/or WS-Notification in mind.
Kobielus is a senior analyst with Burton Group, an IT advisory service that provides in-depth technology analysis for network planners. He can be reached at jkobielus@burtongroup.com.