RE: EndTo testing

I guess Gil concern may be that the To EPR is supposed to be opaque such that the subscriber should not mint it.
But I'm ok either way as this is just a test in a closed world.

Li

________________________________
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Friday, February 04, 2011 2:47 PM
To: Gilbert Pilz
Cc: Li, Li (Li); public-ws-resource-access@w3.org
Subject: Re: EndTo testing


Not sure I'm following the part about "undefined app msg" - I was assuming it would be on all messages - including the Subscribe.  If someone just makes it a ref-param of the wsa:To then no special code is needed on the client to send it.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.

Gilbert Pilz <gilbert.pilz@oracle.com>

02/04/2011 02:38 PM

To

Doug Davis/Raleigh/IBM@IBMUS

cc

"Li, Li (Li)" <lli5@avaya.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>

Subject

Re: EndTo testing










The other difference between your suggestion and Li's is that your header occurs in the context of some, undefined application message from the client to the service whereas Li's is part of the Subscribe request (i.e. an extension). I'm not sure which of these I prefer . . .

~ gp

On 2/4/2011 11:29 AM, Doug Davis wrote:

I'm ok with an EndTime being passed in from the client - this will allow testing w/o manual intervention from a human on the server side.
I have a slight preference for it being under the <sce:Scenario> element I defined though - mainly so that all of the info we pass along for our testing (I've convinced myself we'll need more for other tests too) is in one chunk of XML and not spread across several headers.  But, I'm not too hung up on this if people want separate headers.

ps.  dateTime and duration ?  funny  :-)

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.
"Li, Li (Li)" <lli5@avaya.com><mailto:lli5@avaya.com>
Sent by: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

02/04/2011 02:15 PM


To

"public-ws-resource-access@w3.org"<mailto:public-ws-resource-access@w3.org> <public-ws-resource-access@w3.org><mailto:public-ws-resource-access@w3.org>

cc



Subject

Re: EndTo testing











Doug,

As this is the only extra parameter for the EndTo test, I wonder if it's more useful to allow the subscriber to specify the (premature) end time of the subscription instead. So the header element for the subscriber message would be:
<sce:EndTime>xs:dateTime|xs:duration</sce:EndTime>

where the time should be before the expiry time to instruct the subscription manager to terminate the subscription prematurely.

To support this may require some extra-wse coding in the service logic, which I prefer to minimize. So I'm also ok to just manually stop the service without any header or coding.

Thanks,
Li


All,
I was wondering if people would be ok with adding a well defined SOAP
Header that client can include in messages to the service - something
like:
<sce:Scenario>
<sce:Test> x.y </sce:Test>
</sce:Scenario>

then the service can use this information to know when its suppose to
prematurely terminate a Subscription (or Enumeration) to cause a
SubscriptionEnd message to be sent.  It might be useful in other tests too
but those are the only ones I can think of right now that need something
like this.  People could even just add it as a reference parameter to
their wsa:To EPR then no real specalized client processing would be needed
to cause it to be sent.

Thoughts?

thanks
-Doug

<><><<>><<<>>><<<<<>>>>><<<<<<<<
Li Li, Ph.D.
Dialogue System Research
Avaya Labs Research
233 Mt. Airy Road
Basking Ridge, NJ 07920
Voice: 908-696-5141
Fax: 908-696-5402
Email: lli5@avaya.com<mailto:lli5@avaya.com>
>>>>>>>><><><<>><<<>>><<<<<>>>>>