The IBM WS-RM external endpoint has been updated, info on the
site is at:
   http://dwdemos.dfw.ibm.com/wsrm/index.html

If any of you have some free cycles to spare I'd appreciate
in having you hit it to make sure we didn't regress on
interoperability.  You can have it act as a client to hit
your endpoint.  Also, it supports some of the added functions
some people were testing during the workshop - like request-
response.  See the index.html for more info.

And of course, let me know if things don't act as expected.
-Dug

3 months late.....sorry.
I agree with you. We talked a little about this during the interop event.
To me it falls apart not just for the anonymous case but more importantly
when firewalls are introduced. I'm not sure if the WS-RM or WS-A spec
authors are working on this problem or not - but I'm sure once people
put this into practice they'll be force to address it and a "polling"
mechanism does seem like the easiest solution.
-Dug

Please respond to WS-RM-Workshops@yahoogroups.com

To: WS-RM-Workshops@yahoogroups.com
cc:
Subject: Re: [WS-RM-Workshops] Microsoft endpoint for follow-up testing from the RM Interop Workshop


It's a good observation and I think that this scenario (anonymous
client) is not solved properly in current specs.

The current request/response scenario with an anonymous client:

1. With a short-term invocation, the ACK is returned immediately,
piggy-bagged with the response. When the client receives the response,
it sends the ACK to the server. However, when the server does not
receive an ACK for the response, it has no means of resending the
response and it must consider the response as undelivered.

2. With a long-term invocation, there is no way to send the ACK back in
the HTTP response even if the request was delivered successfully. The
client resends the request again and again in the 'retransmission
interval' and when the response is ready it is sent together with the
ACK as an HTTP response to a resent request (this can be optimized).
Resending the response when no ACK has been received for it presents
these same difficulties.

Both issues can be solved with a polling mechanism. Assuming that
WS-Addressing has a polling mechanism (addressing for 'anonymous'
endpoints), an invocation develops as follows:

The client sends the request. When the server is not able to respond
with an ACK or the response in the 'acknowledgment interval' it returns
a SOAP message (an ACK may be included if the request was delivered)
with a SOAP header signifying 'ask-me-for-response-later.' A
'polling-interval' should also be specified in the endpoint policy. The
client then periodically asks for the response (and ACK) with a SOAP
message and a header signifying 'give-me-response-for-message-<id>'. If
the response (or ACK) is ready, it is sent as an HTTP response to the
polling request. If not, the polling message can be 'accepted (202
status code)'.

I would appreciate hearing your opinions ...


Ales Novy
Software Architect
Systinet


Doug Davis wrote:
>
>
>
>
>
> One interesting thing to note about the end-point is that it seems to only
> send back sync. acks. Which of course makes sense since we're all going to
> have firewalls. However, it means that the chances of people running the
> original scenario we played with (using async acks) probably isn't very
> likely. Spec authors should take serious note of this.
> -Dug
>
>
> "Jorgen Thelin" <jthelin@...> on 10/17/2003 06:19:13 PM
>
> Please respond to WS-RM-Workshops@yahoogroups.com
>
> To: <WS-RM-Workshops@yahoogroups.com>
> cc: "Keith Ballinger" <keithba@...>
> Subject: [WS-RM-Workshops] Microsoft endpoint for follow-up testing from
> the RM Interop Workshop
>
>
> Following the successful initial testing at the RM Interop Workshop this
> week, Microsoft now have an endpoint available for live testing at the
> following address:
>
> http://131.107.72.15/RMWorkshop
>
> All the usual caveats apply – it’s a test machine which may get bounced or
> restarted at any time, there is no guarantee of service level or stuff like
> that, and all the other usual no warranty legalese blah, blah, blah
> applies. You guys know the score!
>
> Anyway, let Keith Ballinger know of any problems you find, and to use one
> of the best lines from a Bond film ever: “Let the mayhem begin…”
>
>
> Jorgen Thelin
> Program Manager, Web Service Protocol Workshops
> Microsoft Corporation
>
>
>
>
> Yahoo! Groups Sponsor
>
>
>
> ADVERTISEMENT
> (Embedded image moved to file: pic30308.gif)Click Here!
>
>
> (Embedded image moved to file: pic17629.gif)
>
>
>
>
> To unsubscribe from this group, send an email to:
> WS-RM-Workshops-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> <http://rd.yahoo.com/M=243273.3860859.5106138.1261774/D=egroupweb/S=1705005512:HM/A=1750744/R=0/SIG=1294umsfu/*http://servedby.advertising.com/click/site=552006/bnum=1066433449695749>
>
>
> To unsubscribe from this group, send an email to:
> WS-RM-Workshops-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/>.
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/IHFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
WS-RM-Workshops-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Was thinking about a possible piggy-backing scenario
and it got me wondering about a couple of things.
In order for piggy-backing to work, for example in
the case where an ACK is sent on a request flow,
the target endpoint of the ACK and of the request
message would need to be the same.  I know that during
the interop our async-endpoint for the ACKs was not
the same as the endpoint for the Ping request, so I
was wondering how people saw this being used in a real-
world situation.  Do people think that the endpoints
(or more accurately the HTTP URLs) will be generic,
something like http://host:port/rmReceiver ?
Seems that they would have to be otherwise you could
never piggy-back anything.  Or is piggy-backing an
interesting concept but in practice might not really be
done.
Thoughts?

>  Right now I was thinking that we could hold the next interop workshop
> during the last week of January - this would give people time to
> enjoy the
> holidays but still have enough time to do whatever code-tweaking
> might be
> necessary.  Thoughts?

The WSDL 2.0 f2f is that week, which I'm hosting at Sonic, so I wouldn't be
able to make that.  I'd much prefer February, if that were doable for the
rest of the group.

Will comment on more substantive stuff after I get to the office later.

--Glen

During the last interop workshop we agreed that we should have a
follow-on
event and I'd like to kick-off that discussion. When comparing what
we did
in the first WS-RM Workshop with the spec we actually covered more
than I
expected. In terms of pure spec topics I believe the ones we didn't
cover are:
  - AckRequest
  - Faults (just the ability to generate and process RM specific
faults)
  - Policy (although there are still open issues related to this one)

  The remaining possible items seemed to be more Q/A issues than pure
spec
issues, and I believe they include:
  - Faults (testing specific contents of the faults)
  . - Due to: Session expiration and Inactivity Timeout
  . - Due to: Reasons covered in section 6 of the spec
  . . - Sequence Terminated
  . . - Unknown Sequence
  . . - Invalid Acknowledgement
  . . - Message Number Rollover
  . . - Last Message Number Exceeded
  . . - Sequence Refused
  - Request/Response
  - Delivery Assurance
  - Piggy-backing

  Having another workshop that focuses strictly on "pure" spec issues
would
probably be pretty quick and boring, so I'd like propose that we try
to go
beyond those and include items from the Q/A list in the scenarios.
Off the
top of my head I can see the list of scenarios looking something
along the
lines of:

0 - Revisit Workshop #1 scenario
I know the spec authors are working their way through the issues that
arose from our first event. If the spec changes before our next
workshop
then we should probably take some time to quickly retest our previous
scenarios based on those changes just to make sure we're all still
covering the basics.  If there is no new spec then we can skip this.

1 - AckRequest Scenario
Simply make sure each receiver can handle an AckRequest message. This
is here
to simple claim spec coverage - I believe there was an open question
from the
last workshop as to the need for this at all.

2 - Faults
Have a sender send a trivial/bad WS-RM message that all receivers
should
fault on.  This will ensure that the receiver can generate at least
one
valid WS-RM fault and that the sender (or I should say the sender's
fault
receiver) can accept it. This will actually test a little bit of WS-
A's
FaultTo processing as well.

3 - Real World Scenario
Develop a scenario in which we use Request/Response and Piggy-
backing. The
contents of the messages do not need to 'real-world' just the data
flow, so
perhaps something along the lines of what Glen suggested during the
first
interop: send a series of messages where the response from the final
one
is the concatenation of all of them. During the event we would need to
do this in two directions to force/test the piggy-backing.

4 - Extensions to #3
Add delivery assurance by having a client send the messages out of
order.
Introduce failures into the flow.
Async vs Sync messages (ie. anonymous Froms).
Force faults mentioned in section 6 of the spec.
Most of these could be done through the development of a single "test
client"
that simply hits all of our receivers.

  Before I went off and wrote up some formal document I wanted to get a
feeling from the group as to whether or not this very high-level
outline
sounds like its going in the right direction. Are there areas I
missed?
Are there other scenarios people would prefer? As with the last event
this
should be community driven so please feel free to comment and offer up
alternatives.

  Right now I was thinking that we could hold the next interop workshop
during the last week of January - this would give people time to
enjoy the
holidays but still have enough time to do whatever code-tweaking
might be
necessary.  Thoughts?

thanks
-Dug

Hi,

When reading the XSD for WS-RM is see "SequenceAcknowledgment" element.
But in specifications at :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html\
/WS-RM-exec-summary.asp
and
http://www-106.ibm.com/developerworks/webservices/library/ws-rm/
I see "SequenceAcknowledg*e*ment" is referenced.
Also the test endpoints that i have tried with simple WS-RM client,
also uses second case.
Is this a typo, or i'm missing something?
So i'm worry about XML validation of WS-RM messages, as they currently
will fail if uses original XSD file as reference.

Best Regards,
Mitko

(reposted to fix an error in the results matrix and maybe the
  formatting will look nicer this time)

WS-RM Interop Workshop Notes
Hosted by IBM at RTP, NC.
Oct 14-16, 2003

Summary:
October 14-16, 2003: The authors of the WS-ReliableMessaging
specification hosted an open 3-day interoperability workshop at
the IBM facility in Research Triangle Park, NC. The participants
included representatives from BEA Systems, Blue Titan, IBM,
Microsoft, NEC Corporation, Sonic Software, Systinet and
TIBCO Software. As with previous Web Service related interoperability
face-to-face meetings, this participant-led event gave implementors
of the WS-ReliableMessaging specification a forum to test their
code with other companies' implementations. The event was a
resounding success on several levels; the extent of interoperability
achieved surpassed the goals laid-out at the start of the event and
the feedback generated for the specification authors focused mainly
on the clarifications of minor issues, but identified no basic
design flaws. Attendees felt that it was important to continue
the momentum of interop testing and to plan on a follow-up event to
test more complex aspects of the specifications.

Agenda:
1. Discuss any show stopping issues with the spec that might
    prevent us from interoperating
2. Discuss the scenario
3. Test
4. Results, summarize spec issues
5. Next steps...

Attendees:

Company           First Name      Last Name
----------------- --------------- ------------
BEA Systems       Matt            Mihic
BlueTitan         Paul            Toth
IBM               Doug            Davis
IBM               Christopher     Ferris
IBM               Robert          Kearney
IBM               Carolyn         Ruby
IBM               Sam             Ruby
Microsoft         Keith           Ballinger
Microsoft         Colleen         Evans
Microsoft         Bruce           Burns
Microsoft         David           Langworthy
Microsoft         Mike            Dice
Microsoft         Jorgen          Thelin
NEC Corporation   Alan            Weissberger
Sonic Software    David           Chappell
Sonic Software    Glen            Daniels
Systinet          Radovan         Janecek
Systinet          Ales            Novy
Systinet          Jiri            Tejkl
Systinet          Robert          Ide
TIBCO Software    Amelia          Lewis

Day 1
------
Notes:
1. No "showstopping" spec issues brought up.
2. Strawman scenario was accepted w/o any changes/additions.
3. Testing Results:

We tested async acks.

Basically, we completed async acks which covered most of the scenario.
The only piece we didn't cover is a disconnected scenario. We agreed
to do that first thing tomorrow: used the remaining time to discuss
our results, issues found today and tomorrow's extended testing
scenarios.

4. Spec Issues Found Today:

From and ReplyTo
- Where does the ack go?
- Where do responses go to if both from and reply headers are present?
- Should this be in the spec?
- Is it specific to a binding? Is it a policy?

Non-contiguous syntax when all are listed in 1+ range.
- Is
   <wsrm:AcknowledgmentRange Lower="1" Upper="2"/>
   <wsrm:AcknowledgmentRange Lower="1" Upper="3"/>...
   valid?
- Spec needs to clarify one way or another

Addressing required for acks?
- Does the RM spec require addressing on an ack message
   (i.e. <to> , <action>)

When they are different Froms (varying EPRs) in a sequence what to do?
- Dave suggests: use the first, ignore the rest

Why is <AckRequested> in the spec? (Systinet)
- Should we test in the next workshop?

Which headers must be marked mU=1?
- Should the spec make anything mandatory?

What does the expiration on a sequence mean?
What to do when the messages keep getting sent?
What does anonymous mean? For <From>? For <ReplyTo>?
How will WS-RM work through firewalls? Polling?

5. Additional Scenarios - the complete list, ordered by preference:

Definite
--------
   Sync ACKs (empty body)
   Disconnect - Each with at least two others

Maybe
-----
   EPR exploding
   Piggybacked (Two-way)

Low pri -- kinda QA testing more than interop testing
-------
   AckRequest testing
   Can we all handle it properly?
   More sophisticated version as well
   Out of order - not much different then disconnected
   Last msg received out of order
   Unreliable router from Dave

Not this time
-------------
   Session expiration
   App-level confirmation/verification test
   DeliveryAssurance testing
   AtMostOnce / InOrder
   Request-response

Day 2
------
Notes:
1. No new spec issues since yesterday.
2. Today's scenarios:

Sonic now has an implementation so we spent some time testing against
it.
Test unplugged - disconnect the server, client starts, after a while
server is reconnect.
Sync acks - server needs to send acks back on the HTTP response flow.
The trigger is the "From" header - if it's the anonymous endpoint
then we send a sync ack back - if it's a non-anonymous endpoint
then we use async acks.

3. Testing Results:

client\server|.Microsoft..Tibco..BEA...Systinet..IBM..Sonic
-------------+-------------------------------------------------------
Microsoft....|.ASD........A......ASDP..ASD.......ASD..AD
Tibco........|.A..........A......A.....A.........A....A
BEA..........|.ASD........A......AS....AS........ASD..AS
Systinet.....|.AS.........A......ASD...ASD.......ASD
IBM..........|.ASD........A......AS....ASD.......ASD..AS
Sonic........|.ASD........A......AS....ASD.......ASD..A
BlueTitan....|.AS.........A......AS....AS........AS

Legend
A: Async ACK
S: Sync ACK
D: Disconnected
P: Piggyback

Notes: Blue Titan is only on the "client" axis because their product
does not have a server-side component.

Disconnected testing was done with just a couple of other
implementations since it's not necessary to hit all endpoints.

4. Spec Issues Found Today:
- None

5. Next steps...
- Since sync acks and disconnected testing went so well we decided to
   examine the remaining additional scenarios. The general consensus was
   that for the most part they should be delayed until the next
   WS-ReliableMessaging Interop Workshop - which people are interesting
   in.
- However, some companies chose to do a little bit of "piggyback"
   testing - represented by the "P"s in the above table.
- Since we accomplished our goal (the original scenario) and even
   went a bit further by testing sync ack we decided to stop a day early.
- Companies will try to host external endpoints.
- We did, of course, still have a nice dinner at Angus Barn.

thanks to everyone who participated!
-Dug

The Systinet WS-RM endpoints are located at:
http://soap.systinet.net/interop/wsrm.html

The request/response endpoint (EchoService) is located there as well if
you are interested in testing the request/response scenario. Both
endpoints (one-way and request/response) work with both anonymous and
non-anonymous clients.

More information about all interop endpoints:
http://soap.systinet.net/interop/index.html


Ales Novy
Software Architect
Systinet

The IBM WS-RM Endpoint is up at:
http://dwdemos.dfw.ibm.com/wsrm

and,fyi, some extra info about the event at:
http://www.ibm.com/developerworks/offers/WS-Specworkshops/ws-
pwrmfest1.html

-Dug

Err.

On Wed, 22 Oct 2003 09:15:41 -0600
Doug Davis <dug@...> wrote:
> 3. Testing Results:
>
>    client\server|  Microsoft  Tibco   BEA     Systinet   IBM     Sonic
>    -------------+----------------------------------------------------
>    --- Microsoft    |  ASD        A       ASDP    ASD        ASD
>    AD Tibco        |  A          A       A       A          A       A
>    BEA          |  ASD        A       AS      AS         ASD     AS
>    Systinet     |  AS         AS      ASD     ASD        ASD
>    IBM          |  ASD        A       AS      ASD        ASD     AS
>    Sonic        |  ASD        AS      AS      ASD        ASD     A
>    BlueTitan    |  AS         A       AS      AS         AS
>
>    Legend
>    A: Async ACK
>    S: Sync ACK
>    D: Disconnected
>    P: Piggyback

I don't think so.  TIBCO is showing as responding synchronously (read
down the TIBCO server column), which is simply impossible.  I believe
that we did do some disconnected testing as well, but don't remember
with whom, at the moment (hmm, that was around the time that I was
fighting with the network, as well).

In any event, Sonic and Systinet could not possibly have gotten
synchronous acks from TIBCO.  Maybe these were the people that I did
disconnected stuff with?  Don't remember, sorry.

Amy!
--
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@...

WS-RM Interop Workshop Notes
                           Hosted by IBM at RTP, NC.
                                Oct 14-16, 2003

Summary:
October 14-16, 2003: The authors of the WS-ReliableMessaging specification
hosted an open 3-day interoperability workshop at the IBM facility in
Research
Triangle Park, NC.  The participants included representatives from BEA
Systems,
Blue Titan, IBM, Microsoft, NEC Corporation, Sonic Software, Systinet and
TIBCO Software.  As with previous Web Service related interoperability
face-to-face meetings, this participant-led event gave implementors of the
WS-ReliableMessaging specification a forum to test their code with other
companies' implementations.  The event was a resounding success on several
levels; the extent of interoperability achieved surpassed the goals
laid-out
at the start of the event and the feedback generated for the specification
authors focused mainly on the clarifications of minor issues, but
identified
no basic design flaws.  Attendees felt that it was important to continue
the
momentum of interop testing and to plan on a follow-up event to test more
complex aspects of the specifications.

Agenda:
1. Discuss any show stopping issues with the spec that might prevent us
    from interoperating
2. Discuss the scenario
3. Test
4. Results, summarize spec issues
5. Next steps...

    Attendees:

    Company                 First Name      Last Name
    -----------------       --------------- ------------
    BEA Systems             Matt            Mihic
    BlueTitan               Paul            Toth
    IBM                     Doug            Davis
    IBM                     Christopher     Ferris
    IBM                     Robert          Kearney
    IBM                     Carolyn         Ruby
    IBM                     Sam             Ruby
    Microsoft               Keith           Ballinger
    Microsoft               Colleen         Evans
    Microsoft               Bruce           Burns
    Microsoft               David           Langworthy
    Microsoft               Mike            Dice
    Microsoft               Jorgen          Thelin
    NEC Corporation         Alan            Weissberger
    Sonic Software          David           Chappell
    Sonic Software          Glen            Daniels
    Systinet                Radovan         Janecek
    Systinet                Ales            Novy
    Systinet                Jiri            Tejkl
    Systinet                Robert          Ide
    TIBCO Software          Amelia          Lewis

Day 1
------
Notes:
1. No "showstopping" spec issues brought up.
2. Strawman scenario was accepted w/o any changes/additions.
3. Testing Results:

    We tested async acks.

    Basically, we completed async acks which covered most of the scenario.
    The only piece we didn't cover is a disconnected scenario.  We agreed to
    do that first thing tomorrow: used the remaining time to discuss our
    results, issues found today and tomorrow's extended testing scenarios.

4. Spec Issues Found Today:

    From and ReplyTo
      - Where does the ack go?
      - Where do responses go to if both from and reply headers are present?
      - Should this be in the spec?
      - Is it specific to a binding? Is it a policy?
    Non-contiguous syntax when all are listed in 1+ range.
      - Is
        <wsrm:AcknowledgmentRange Lower="1" Upper="2"/>
        <wsrm:AcknowledgmentRange Lower="1" Upper="3"/>...
        valid?
      - Spec needs to clarify one way or another
    Addressing required for acks?
      - Does the RM spec require addressing on an ack message
        (i.e. <to> , <action>)
    When they are different Froms (varying EPRs) in a sequence what to do?
      - Dave suggests: use the first, ignore the rest
    Why is <AckRequested> in the spec? (Systinet)
      - Should we test in the next workshop?
    Which headers must be marked mU=1?
      - Should the spec make anything mandatory?
    What does the expiration on a sequence mean?
    What to do when the messages keep getting sent…
    What does anonymous mean? For <From>? For <ReplyTo>?
    How will WS-RM work through firewalls? Polling?

5. Additional Scenarios - the complete list, ordered by preference:

    Definite
      Sync ACKs (empty body)
      Disconnect - Each with at least two others
      Maybe
      EPR exploding
      Piggybacked (Two-way)
    Low pri -- kinda QA testing more than interop testing
      AckRequest testing
      Can we all handle it properly?
      More sophisticated version as well
      Out of order - not much different then disconnected
      Last msg received out of order
      Unreliable router from Dave
    Not this time
      Session expiration
      App-level confirmation/verification test
      DeliveryAssurance testing
      AtMostOnce / InOrder
      Request-response

Day 2
------
Notes:
1. No new spec issues since yesterday.
2. Today's scenarios:

    Sonic now has an implementation so we spent some time testing against
it.
    Test unplugged - disconnect the server, client starts, after a while
    server is reconnect.
    Sync acks - server needs to send acks back on the HTTP response flow.
The
    trigger is the "From" header - if it’s the anonymous endpoint then we
send
    a sync ack back - if it’s a non-anonymous endpoint then we use async
acks.

3. Testing Results:

    client\server|  Microsoft  Tibco   BEA     Systinet   IBM     Sonic
    -------------+-------------------------------------------------------
    Microsoft    |  ASD        A       ASDP    ASD        ASD     AD
    Tibco        |  A          A       A       A          A       A
    BEA          |  ASD        A       AS      AS         ASD     AS
    Systinet     |  AS         AS      ASD     ASD        ASD
    IBM          |  ASD        A       AS      ASD        ASD     AS
    Sonic        |  ASD        AS      AS      ASD        ASD     A
    BlueTitan    |  AS         A       AS      AS         AS

    Legend
    A: Async ACK
    S: Sync ACK
    D: Disconnected
    P: Piggyback

    Notes: Blue Titan is only on the "client" axis because their product
does
           not have a server-side component.

           Disconnected testing was done with just a couple of other
           implementations since it's not necessary to hit all endpoints.

4. Spec Issues Found Today:
    - None

5. Next steps...
    - Since sync acks and disconnected testing went so well we decided to
      examine the remaining additional scenarios.  The general consensus was
      that for the most part they should be delayed until the next
      WS-ReliableMessaging Interop Workshop - which people are interesting
in.
    - However, some companies chose to do a little bit of "piggyback"
      testing - represented by the "P"s in the above table.
    - Since we accomplished our goal (the original scenario) and even went a
      bit further by testing sync ack we decided to stop a day early.
    - Companies will try to host external endpoints.
    - We did, of course, still have a nice dinner at Angus Barn.

thanks to everyone who participated!
-Dug

Doug Davis wrote:

 
 
 
 

This wold be a good time to remind all of the participants to please post a
URL to their endpoint when/if it becomes available.  IBM's will be
available soon.
-Dug
 

To unsubscribe from this group, send an email to:
WS-RM-Workshops-unsubscribe@yahoogroups.com
 
 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

--
Sonic Software - Changing the Economics of Integration
--
David Chappell <chappell@...> Office: (781)999-7099 Mobile: (617)510-6566
Vice President and Chief Technology Evangelist
Technology Advancement Group, Sonic Software
co-author,"Java Web Services" (O'Reilly), "The Java Message Service" (O'Reilly),
"Professional ebXML Foundations", (Wrox Press)
--
 

I'm in the process of putting together the summary and
wanted to give people one last chance to opt-out of having
their results posted to this mailing-list/group. If you wish
to have your results removed from the matrix that will be
included in the summary please let me know - either through
this list or in a private email by tomorrow morning
(around 9am eastern).
thanks,
-Dug

This wold be a good time to remind all of the participants to please post a
URL to their endpoint when/if it becomes available.  IBM's will be
available soon.
-Dug

It's a good observation and I think that this scenario (anonymous
client) is not solved properly in current specs.

The current request/response scenario with an anonymous client:

1. With a short-term invocation, the ACK is returned immediately,
piggy-bagged with the response. When the client receives the response,
it sends the ACK to the server. However, when the server does not
receive an ACK for the response, it has no means of resending the
response and it must consider the response as undelivered.

2. With a long-term invocation, there is no way to send the ACK back in
the HTTP response even if the request was delivered successfully. The
client resends the request again and again in the 'retransmission
interval' and when the response is ready it is sent together with the
ACK as an HTTP response to a resent request (this can be optimized).
Resending the response when no ACK has been received for it presents
these same difficulties.

Both issues can be solved with a polling mechanism. Assuming that
WS-Addressing has a polling mechanism (addressing for 'anonymous'
endpoints), an invocation develops as follows:

The client sends the request. When the server is not able to respond
with an ACK or the response in the 'acknowledgment interval' it returns
a SOAP message (an ACK may be included if the request was delivered)
with a SOAP header signifying 'ask-me-for-response-later.' A
'polling-interval' should also be specified in the endpoint policy. The
client then periodically asks for the response (and ACK) with a SOAP
message and a header signifying 'give-me-response-for-message-<id>'. If
the response (or ACK) is ready, it is sent as an HTTP response to the
polling request. If not, the polling message can be 'accepted (202
status code)'.

I would appreciate hearing your opinions ...


Ales Novy
Software Architect
Systinet


Doug Davis wrote:
>
>
>
>
>
> One interesting thing to note about the end-point is that it seems to only
> send back sync. acks.  Which of course makes sense since we're all going to
> have firewalls.  However, it means that the chances of people running the
> original scenario we played with (using async acks) probably isn't very
> likely.  Spec authors should take serious note of this.
> -Dug
>
>
> "Jorgen Thelin" <jthelin@...> on 10/17/2003 06:19:13 PM
>
> Please respond to WS-RM-Workshops@yahoogroups.com
>
> To:    <WS-RM-Workshops@yahoogroups.com>
> cc:    "Keith Ballinger" <keithba@...>
> Subject:    [WS-RM-Workshops] Microsoft endpoint for follow-up testing from
>        the RM Interop Workshop
>
>
> Following the successful initial testing at the RM Interop Workshop this
> week, Microsoft now have an endpoint available for live testing at the
> following address:
>
> http://131.107.72.15/RMWorkshop
>
> All the usual caveats apply – it’s a test machine which may get bounced or
> restarted at any time, there is no guarantee of service level or stuff like
> that, and all the other usual no warranty legalese blah, blah, blah
> applies. You guys know the score!
>
> Anyway, let Keith Ballinger know of any problems you find, and to use one
> of the best lines from a Bond film ever: “Let the mayhem begin…”
>
>
> Jorgen Thelin
> Program Manager, Web Service Protocol Workshops
> Microsoft Corporation
>
>
>
>
>                     Yahoo! Groups Sponsor
>
>
>
>                         ADVERTISEMENT
>    (Embedded image moved to file: pic30308.gif)Click Here!
>
>
> (Embedded image moved to file: pic17629.gif)
>
>
>
>
> To unsubscribe from this group, send an email to:
> WS-RM-Workshops-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
>
<http://rd.yahoo.com/M=243273.3860859.5106138.1261774/D=egroupweb/S=1705005512:H\
M/A=1750744/R=0/SIG=1294umsfu/*http://servedby.advertising.com/click/site=552006\
/bnum=1066433449695749>
>
>
> To unsubscribe from this group, send an email to:
> WS-RM-Workshops-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/>.
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>

As of now I know that IBM and MS will be posting summaries on their
external web sites - I suspect that BEA and TIBCO probably will as well
(just haven't heard officially if they will or not).  So that will be some
PR.  Not aware of any other efforts at this time, but as they develop we'll
post them to this group.
-Dug


David Chappell <chappell@...> on 10/16/2003 07:30:52 AM

Please respond to WS-RM-Workshops@yahoogroups.com

To:    WS-RM-Workshops@yahoogroups.com
cc:
Subject:    Re: [WS-RM-Workshops] Disclosure



Is there any sanctioned PR efforts that we can participate in with regard
to this workshop?
Dave

Doug Davis wrote:




Yes to all.
-Dug


"dave_chappell2003" <chappell@...> on 10/16/2003 06:33:27 AM

Please respond to WS-RM-Workshops@yahoogroups.com

To:��� WS-RM-Workshops@yahoogroups.com
cc:
Subject:��� [WS-RM-Workshops] Disclosure


Just to be crystal clear on the non-disclosure issues.� The way I
understand it -
- We can talk publicly about the event, the nature of the test
scenarios, and the names of the companies that participated.
- We can't talk about the results...although the results turned out
to be favorable for all concerned, right?
Dave



To unsubscribe from this group, send an email to:
WS-RM-Workshops-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







To unsubscribe from this group, send an email to:
WS-RM-Workshops-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

--
Sonic Software - Changing the Economics of Integration
--
David Chappell <chappell@...> Office: (781)999-7099 Mobile:
(617)510-6566
Vice President and Chief Technology Evangelist
Technology Advancement Group, Sonic Software
co-author,"Java Web Services" (O'Reilly), "The Java Message Service"
(O'Reilly),
"Professional ebXML Foundations", (Wrox Press)
--

(Embedded image moved to file: pic13286.jpg)
(Embedded image moved to file: pic15143.jpg)

One interesting thing to note about the end-point is that it seems to only
send back sync. acks.  Which of course makes sense since we're all going to
have firewalls.  However, it means that the chances of people running the
original scenario we played with (using async acks) probably isn't very
likely.  Spec authors should take serious note of this.
-Dug


"Jorgen Thelin" <jthelin@...> on 10/17/2003 06:19:13 PM

Please respond to WS-RM-Workshops@yahoogroups.com

To:    <WS-RM-Workshops@yahoogroups.com>
cc:    "Keith Ballinger" <keithba@...>
Subject:    [WS-RM-Workshops] Microsoft endpoint for follow-up testing from
        the RM Interop Workshop


Following the successful initial testing at the RM Interop Workshop this
week, Microsoft now have an endpoint available for live testing at the
following address:

http://131.107.72.15/RMWorkshop

All the usual caveats apply – it’s a test machine which may get bounced or
restarted at any time, there is no guarantee of service level or stuff like
that, and all the other usual no warranty legalese blah, blah, blah
applies. You guys know the score!

Anyway, let Keith Ballinger know of any problems you find, and to use one
of the best lines from a Bond film ever: “Let the mayhem begin…”


Jorgen Thelin
Program Manager, Web Service Protocol Workshops
Microsoft Corporation




                     Yahoo! Groups Sponsor



                         ADVERTISEMENT
    (Embedded image moved to file: pic30308.gif)Click Here!


  (Embedded image moved to file: pic17629.gif)




To unsubscribe from this group, send an email to:
WS-RM-Workshops-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Doug Davis wrote:

 
 
 
 

Yes to all.
-Dug
 

"dave_chappell2003" <chappell@...> on 10/16/2003 06:33:27 AM

Please respond to WS-RM-Workshops@yahoogroups.com

To:    WS-RM-Workshops@yahoogroups.com
cc:
Subject:    [WS-RM-Workshops] Disclosure
 

Just to be crystal clear on the non-disclosure issues.  The way I
understand it -
- We can talk publicly about the event, the nature of the test
scenarios, and the names of the companies that participated.
- We can't talk about the results...although the results turned out
to be favorable for all concerned, right?
Dave
 
 

To unsubscribe from this group, send an email to:
WS-RM-Workshops-unsubscribe@yahoogroups.com
 
 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
 
 
 
 
 

To unsubscribe from this group, send an email to:
WS-RM-Workshops-unsubscribe@yahoogroups.com
 
 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

--
Sonic Software - Changing the Economics of Integration
--
David Chappell <chappell@...> Office: (781)999-7099 Mobile: (617)510-6566
Vice President and Chief Technology Evangelist
Technology Advancement Group, Sonic Software
co-author,"Java Web Services" (O'Reilly), "The Java Message Service" (O'Reilly),
"Professional ebXML Foundations", (Wrox Press)
--
 

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the WS-RM-Workshops
group.

   File        : /Scenarios.doc
   Uploaded by : dugibm <dug@...>
   Description : Initial Scenario

You can access this file at the URL

http://groups.yahoo.com/group/WS-RM-Workshops/files/Scenarios.doc

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

dugibm <dug@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the WS-RM-Workshops
group.

   File        : /RM workshop agreement 9-23-03.doc
   Uploaded by : dugibm <dug@...>
   Description : Legal Agreement

You can access this file at the URL

http://groups.yahoo.com/group/WS-RM-Workshops/files/RM%20workshop%20agreement%20\
9-23-03.doc

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

dugibm <dug@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the WS-RM-Workshops
group.

   File        : /logistics.doc
   Uploaded by : dugibm <dug@...>
   Description : Logistics

You can access this file at the URL

http://groups.yahoo.com/group/WS-RM-Workshops/files/logistics.doc

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

dugibm <dug@...>

Just to have it in our history, here's the 2nd invite that was sent out
-Dug


The authors of the WS-ReliableMessaging specification are hosting a 3-day
hands-on, interop workshop in October.  The dates and times for this
workshop are Oct 14 and 15 (9am to 6 pm) and Oct 16 (9am to 12pm).  This
workshop will be for companies who have ReliableMessaging implementations
based on the WS-ReliableMessaging specification published March 13, 2003,
who want to test their implementations with other companies’
implementations.

This workshop is an ad-hoc, open forum for companies to test their
WS-ReliableMessaging implementations.  Attendees bring their own laptops,
their implementations and any other tools they feel would be needed;
testing among all attendees will occur throughout the day.  Progress of
interoperating implementations will be tracked throughout the event.

This workshop will be held in Building 002 (Cafe B) at the IBM facility in
Raleigh, North Carolina.  For more up-to-date information on the location
please visit one of the following sites:

http://www-106.ibm.com/developerworks/offers/WS-Specworkshops/
http://msdn.microsoft.com/webservices/community/workshops/default.aspx

A network will be provided for the workshop, and a scenario will be
provided to
attendees before the workshop.   Breakfast and lunch will be served all 3
days; dinner will be provided Wed, Oct 15.

As with previous workshops, this event is open to anyone who desires to
participate and has an implementation based on the WS-ReliableMessaging
Specification. The list of attendees and general workshop results will be
made public after the workshop. In order to make the event as productive as
a possible, included is a set of scenarios which will be the used as the
basis for the interoperability.

If you are interested in participating, please reply to Doug Davis at
dug@....  Feel free to pass this invitation along, either in your
company or elsewhere.  This is an open forum.  No invitation is required.

Note that in order to attend, the attached legal agreement MUST be signed
by each attendee.

Thank you and we look forward to your participation.

Name from company
Title
Company
Email address

Carolyn Ruby
rubyc@...

(See attached file: Scenarios.doc)(See attached file: logistics.doc)(See
attached file: RM workshop agreement 9-23-03.doc)

Yes to all.
-Dug


"dave_chappell2003" <chappell@...> on 10/16/2003 06:33:27 AM

Please respond to WS-RM-Workshops@yahoogroups.com

To:    WS-RM-Workshops@yahoogroups.com
cc:
Subject:    [WS-RM-Workshops] Disclosure


Just to be crystal clear on the non-disclosure issues.  The way I
understand it -
- We can talk publicly about the event, the nature of the test
scenarios, and the names of the companies that participated.
- We can't talk about the results...although the results turned out
to be favorable for all concerned, right?
Dave



To unsubscribe from this group, send an email to:
WS-RM-Workshops-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Just to be crystal clear on the non-disclosure issues.  The way I
understand it -
- We can talk publicly about the event, the nature of the test
scenarios, and the names of the companies that participated.
- We can't talk about the results...although the results turned out
to be favorable for all concerned, right?
Dave

Given the feedback from some of the respondents to the September RM
interop workshop, the authors (BEA, IBM, Microsoft and TIBCO) have
decided to move the workshop date to accommodate more participants.
The new dates are October 14th-16th, 2003.

The agenda for the workshop:

       Oct 14-15, 9-6 EST
             Two full days of interop testing

       Oct 16, 9-12 EST
             Continued interop testing
             Documentation of technical concerns and/or
               recommendations identified during the workshop
             Follow-on discussions regarding future RM interop
               workshops

We'll get more of an update out soon - just wanted to give you as
much lead time as possible on the dates.   The event will be held in
the Research Triangle Park in North Carolina.

At the end of the note you'll find a list of hotels in the RTP area.
Please contact me if you plan to attend or if you have any questions.

Thanks
-Doug

Doug Davis
dug@...

Wellesley Inn and Suites
       4919 South Miami Blvd, Durham, NC 27703
       ph: 919-998-0400

Comfort Suites
       5219 Page Rd, Durham, NC 27703
       ph: 919-314-1200

Wyndham Garden Hotel
       4620 South Miami Blvd, Durham, NC 27703
       ph: 919-941-6066

Homewood Suites
       4603 Central Park Dr, Durham, NC 27703
       ph: 919-474-9900

Clarion Hotel
       4912 South Miami Blvd, Durham, NC 27709
       ph: 919-474-9800

Holiday Inn
       4810 Old Page Rd, RTP, NC, 27709
       ph: 919-941-6000

Radisson Governors Inn
       I-40 at Davis Dr, RTP, NC 27709
       ph: 919-549-8631

Sheraton Imperial Hotel & Convention Center
       4700 Emperor Blvd, Durham, NC 27709
       ph: 919-941-5050