Issue Details (XML | Word | Printable)

Key: WISEMAN-21
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: obiwan314
Reporter: obiwan314
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
wiseman

Add Eventing Support to Client

Created: 18/Aug/06 09:05 AM   Updated: 06/Aug/07 01:42 PM
Component/s: client
Affects Version/s: current
Fix Version/s: milestone 1

Time Tracking:
Not Specified

Environment:

Operating System: All
Platform: All


Issuezilla Id: 21
Tags:
Participants: obiwan314 and simeonpinder


 Description  « Hide

The client has no support for eventing beyond what is already present in
wiseman. This should be enhanced to include an Observer Pattern based way to
create listeners and bind their events to java objects inside a client
application, optionally using JAXB on the received events. A method of creating
a simple listener for J2SE environments should also be provided.



simeonpinder added a comment - 06/Aug/07 01:42 PM

Upon further investigation it was discovered that a full implementation of
WS-Eventing as described via WS-Management quickly involves model specific
decisions, which makes this task of defining generic helper functionality
non-trivial. This is a result of insufficient direction when building eventing
implementations from the WS-Management and WS-Eventing specifications. To
further demonstrate this explanation the following questions, required to
successfully build client side eventing were uncovered:

  • How does one find a list of subscribers to subscribe to? Currently apriori
    knowledge of subscriptions is assumed.
  • To successfully interact with an eventing implementation, how does one
    determine what strategy is to be used to access the events being generated? Is
    it PUSH/PULL/Custom mechanism? Assuming the approach is known, how does one
    find/learn the symantics of using the Eventing mechanism defined? Should a
    client framework provide support for PUSH/PULL out of the box only? Is there a
    more generic approach to subscription/Events?
  • How does one find out what the Event message payloads look like so that they
    may be processed? Event payloads are custom by definition?

These are just a few of the model specific implementation details that made this
task much more difficult than originally assumed.

This task has been deferred for later releases until more direction from
users/consumers emerges.