[jbossws-users] WS-Eventing: wsa:ReferenceParameters and multiple sources

[Dan Retzlaff]

Hi,

I have two issues to discuss regarding the WS-Eventing extension to JBossWS.

1. Notifications don't reflect the wsa:ReferenceParameters provided
with subscriptions' NotifyTo and EndTo wsa:EndpointReferences. If my
understanding of WS-A is correct, each reference parameter should
appear as a top-level element in the SOAP header of notifications. Is
this not the case? I need it for a "SubscriptionID" field that allows
a recipient to identify the subscription which resulted in the
notification. The first patch, WSE-ReferenceParameters.patch,
introduces the desired behavior. I have to admit, I'm fuzzy on the
distinction between ReferenceParameters and ReferenceProperties. If
it's only the latter which is meant to have this behavior (as it is in
the examples in the WS-Eventing spec), then I can modify my
implementation and this patch.

2. Deploying a single event source, as in the sample provided, worked
fine. However, I ran into two problems with more than one event source
in the same deployment. Both problems are addressed in the second
patch, WSE-SourceInit.patch.

The first initialization bug was in
MetaDataBuilder::processEndpointMetaDataExtensions. This method is
called for each endpoint, and goes through the service's WSDL looking
for wsdl:portTypes with a wse:isEventSource attribute. For each such
portType, a EventingEpMetaExt extension is added to a map in
ServerEndpointMetadata indexed by the WS-E namespace. However, since
the namespace is the same for all such portTypes, only the last one
sticks around. Then during deployment, the EventingDeploymentAspect
registers each event source with the SubscriptionManager, but the
EventingEndpointDeployment has the wrong eventSourceNS for all but the
last portType processed by the MetaDataBuilder. The
SubscriptionManager depends on an eventSourceNS being registered
exactly twice: once for the source endpoint and once for the
subscription manager endpoint. But since the eventSourceNS for the
last portType gets registered twice, neither of which is the
subscription manager, the premature transition of the source to the
STARTED state causes its assertConfiguration() to fail. My solution is
to modify MetaDataBuilder::processEndpointMetaDataExtensions to not
add the EventingEpMetaExt for event sources that don't correspond to
the current endpoint's address. The SubscriptionManagerPort
(identified by the same dodgy string-literal comparison used in the
SubscriptionManager class) still gets all sources' EventingEpMetaExts.

The second initialization bug was that SubscriptionManager's
registerEventSource didn't ensure that all event sources went through
CREATED and STARTED states. In my case, this manifested itself with a
NullPointerException when an un-started EventSource tried to deliver a
notification. The patch refactors registerEventSource (and its
protected helper, updateManagerAddress). There's probably room for a
little polish here, but it works and I've spent too much time on this
already. :)

On a design note, I'm finding it cumbersome to have the event source
derive its URI from its WSDL portType QName. This, along with the
annotation approach to creating a non-abstract endpoint class,
requires a lot more configuration per event source than it feels like
should be necessary: a new portType, a new binding, a new service
port, a new servlet in web.xml, plus a new Java file that needs to be
compiled. Right now I'm autocoding all of these from a single source
XML (a custom annotated WSDL), but is this the best way? Does someone
have a suggestion for me?

Regards,
Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WSE-ReferenceParameters.patch
Type: application/octet-stream
Size: 2936 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbossws-users/attachments/20080124/6b9a4b44/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WSE-SourceInit.patch
Type: application/octet-stream
Size: 8151 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbossws-users/attachments/20080124/6b9a4b44/attachment-0001.obj