From my point of view Event Driven Architecture (EDA) is part of SOA and typically run with push(like) setups (pub/sub). Most of the SOA talk has been on request/response oriented setups, probably cause by the common usage of HTTP and no agreed upon interfaces for subscriptions/topics. In this blogpost I'll have a quick look at the OASIS standard Web Services Notification (WSN).
Web Services Notification (WSN) setup
The committee was started back in 2004 when the proposed standard was submitted to OASIS:
The OASIS WSN Technical Committee will coordinate efforts with the OASIS Web Services Resource Framework (WSRF) Technical Committee (also announced today). Members of the OASIS WSN Technical Committee plan to conform their work to the implied resource pattern specified by WSRF and will make use of WSRF specifications concerning lifetime and properties.
So it has a close relation with Web Services Resource Framework (WSRF). The homepage for the OASIS Web Services Notification (WSN) TC has the following overview:
The purpose of the Web Services Notification (WSN) TC is to define a set of specifications that standardise the way Web services interact using "Notifications" or "Events". They form the foundation for Event Driven Architectures built using Web services.
These specifications provide a standardized way for a Web service, or other entity, to disseminate information to a set of other Web services, without having to have prior knowledge of these other Web Services. They can be thought of as defining "Publish/Subscribe for Web services".
Two years later in October 2006 they announced that its members had approved the WS-BaseNotification, WS-BrokeredNotification and WS-Topics specifications as OASIS standards. A simpel and in my opion relevant indicator of chance for succes (for a ws-* standard) is which companies approved the standard, and here it was:
- AmberPoint
- CA
- Fujitsu
- HP
- Hitachi
- IBM
- Oracle
- SAP
- Sonic Software
- Tibco
- webMethods
There are certainly a lot of big companies supporting (with a degree of holeheartness), but in my view Microsoft is missing and to some degree Sun.
Implementation
If a standard is to be used theres a need for (widespread) implementation. OASIS has as part of the standardization process a requiment of several practical implementations (like ex. the w3c). At the time when the standard was approved is was (taken from the announcement):
Amberpoint, Fujitsu, and IBM have all implemented WS-Notification either internally or externally (in keeping with the consortium's requirement that at least three parties assert successful implementation prior to OASIS Standard balloting). Fujitsu's implementation is available as open source tool through unicore.forge.net.
The reference to the Fujitsu open source implementation isn't active anymore but the Apache Muse project does:
The Apache Muse Project is a Java-based implementation of the WS-ResourceFramework (WSRF), WS-BaseNotification (WSN), and WS-DistributedManagement (WSDM) specifications. It is a framework upon which users can build web service interfaces for manageable resources without having to implement all of the "plumbing" described by the aforementioned standards. Applications built with Muse can be deployed in both Apache Axis2 and OSGi environments, and the project includes a set of command line tools that can generate the proper artifacts for your deployment scenario.
The implementation of WSN is only partial, with only WS-BaseNotification of the three specifications that make up the standard.
Update: IBM has support for WSN in their WebSphere suite.
The standard for Web Services Notification (WSN)
To get a more detailed view of the features offered by the three specifications:
- WS-BaseNotification 1.3 OASIS Standard (In PDF it's 68 pages)
- WS-BrokeredNotification 1.3 OASIS Standard (In PDF it's 43 pages)
- WS-Topics 1.3 OASIS Standard (In PDF it's 40 pages)
let's look at their goals and requirements.
WS-BaseNotification
Goal
The goal of WS-BaseNotification is to standardize the terminology, concepts, operations, WSDL and XML needed to express the basic roles involved in Web services publish and subscribe for notification message exchange.
Requirements
- Must support resource-constrained devices.
- The specifications must be factored in a way that allows resource-constrained devices to participate in the Notification pattern. Such devices will be able to send information to, and receive information from Web services, without having to implement all the features of the specifications.
- Must provide runtime metadata
- There must be a mechanism that lets a potential Subscriber discover what elements are provided for subscription by a NotificationProducer, and in what formats the subscription for notification can be made.
- WS-BaseNotification must be independent of binding-level details
- Transport protocol details must be orthogonal to the subscription and the delivery of the notifications, so that the specification can be used over a variety of different transports.
- Must allow for Message Oriented Middleware implementations.
- The design of the WS-BaseNotification must allow a service that is acting as a NotificationProducer to delegate its implementation of WS-BaseNotification semantics to a Message Oriented Middleware provider.
- Relationship to other WS-* specifications
- WS-BaseNotification must be composable with other Web services specifications.
WS-BrokeredNotificatio
Goal
The goal of WS-BrokeredNotification is to standardize message exchanges involved in Web services publish and subscribe of a message broker. The overall requirements of WS-Notification are presented in [WS-BaseNotification]. The following section lists the specific subset of those objectives realized by WS-BrokeredNotification.
Requirements
- Must allow for a notification broker as an intermediary.
- A NotificationBroker is an intermediary Web service that decouples NotificationConsumers from Publishers. A notification broker can relieve a Publisher from having to implement message exchanges associated with NotificationProducer; the NotificationBroker takes on the duties of subscription management and distributing Notifications on behalf of the Publisher. It implements NotificationProducer interface. It may implement SubscriptionManager or may delegate the subscription management work to another component.
- Must allow for federation of brokers.
- It must be possible to build configurations with multiple intermediary broker services in a dynamic fashion. This specification must allow for a variety of broker topology usage patterns. Among other things, these allow for greater scalability and permit sharing of administrative workload.
- Must provide runtime metadata.
- There must be a mechanism that lets a potential Subscriber discover what elements available for a subscription are provided by a NotificationBroker, and in what formats the subscription for a notification can be made.
- Must conform to WS-BaseNotification.
- A NotificationBroker must support required message exchanges defined by the [WS-BaseNotification] specification. It must conform to the NotificationProducer and the NotificationConsumer interfaces defined in WS-BaseNotification.
- WS-BrokeredNotification must be independent of binding-level details.
- Transport protocol details must be orthogonal to the subscription and the delivery of the notifications, so that the specification can be used over a variety of different transports.
- Must not exclude non-service producers and subscribers.
- WS-BrokeredNotification design must not exclude a non-service entity to deliver a notification message to a NotificationBroker. It must not exclude a NotificationBroker to send a notification message to a non-service consumer.
- Must provide publisher registration.
- WS-BrokeredNotification must define standard message exchanges for registering a NotificationPublisher with a NotificationBroker.
WS-Topics
Goal
The goal of the WS-Topics specification is to define a mechanism to organize and categorize items of interest for subscription known as “topics”. It defines a set of topic expression dialects that can be used as subscription expressions in subscribe request messages and other parts of the WS-Notification system.
Requirements
- Must support resource-constrained devices.
- The specifications must be factored in a way that allows resource-constrained devices to participate in the Notification pattern. Such devices will be able to send information to, and receive information from Web services, without having to implement all the features of the specifications.
- Must permit transformation and aggregation of Topics.
- It must be possible to construct configurations (using intermediary brokers) where the Topic subscribed to by the NotificationConsumer differs from the Topic published to by the NotificationProducer, yet Notifications from the NotificationProducer are routed to the NotificationConsumer by a broker that is acting according to administratively-defined rules.
- Must permit non-centralized development of a topic tree.
- It must be possible for actors to define additional topics based on existing topics without requiring coordination with the actor responsible for creating the topics that are being built on.
Conclusion
If I were to spot the "Achilles' heel" of the WS-* stack, it must be the lack of a standard to really replace the classic messaging setups like ex. JMS, though that was what many set out for. It took an incredible long time to finally get something like WSN and even more importantly WS-RX. And that is just the standards - then you have to wait for at product near you to support it! In the meantime some has lost confidence (and maybe gained productivity) but using more propriotairy standards making it even harder to gain critical attraction.
Doing a web search for wsn gives far fewer interesting hits than I would have liked to see. This indicates to me that though WSN has alot to offer the real usage is strongly limited.
0 comments :
Post a Comment