This mailing list has been a bit quiet recently. I have actually been
busy implementing WS-Notification, and am at a stage where it is time
for some more interop testing.
This is surprisingly hard, as I cannot actually receive events at work;
I can only test against remote systems from home. XMPP notification is
much easier.
1. I will bring the HP system up and running with WS-N support on
friday. I'm not convinced it generates all the events, at the right time.
2. I've been test subscribing against the ourgrid implementation. I can
see that I can subscribe to events, but havent been able to test for
incoming events. This is where we will find any incompatibilities
between my reading of the WS-N spec and that of the Muse team.
3. I note that our CMP/deployapi tests don't take into account the
possibility that events get received in a different order from that of
the lifecycle. It seems to me that this is not actually precluded from
the WS-N/SOAP protocols, especially WS-N over things other than HTTP, or
with pooled notification threads (which is what I have for generating
non-blocking notifications)
How do people test state transitions -do they explicitly test for
components walking through the expected lifecycle, or is it ok for
events to come back out of order, provided the clock order of sent
messages matches?
4. A draft document on testing the specification. Stephen Pickles was
interested in this, so I added it to my list of deliverables. I dont
have any coverage of CMP testing, if anyone else wants to volunterer.
5. Jun, can you make sure the NEC endpoint is up and running next week.
If I can successfully subscribe and listen to the Ourgrid
implementation, then I should be able to work with yours, but I would
like to do it just to check off the 'all is complete' box in the
interoperability document.
-steve
