Re: [sca-j] testing architecture

[David Booz <booz@us.ibm.com>]

I'll try to clarify the "two runtime" question. In my charts, the two runtimes are meant to be from the same vendor. The last bullet on the first slide was supposed to make this clear.

From the whiteboard pic, the two runtimes are indeed from different vendors but runtime 2 was added to the board as part of a different discussion not addressed by the slides. That larger discussion was about what constitutes a compliant runtime, which bindings needed to be supported, etc. We didn't come to any conclusions on this discussion, thus I did not include it in the slides.

We certainly don't need two runtimes (even from the same vendor) for all the tests, but we need it for some of the tests. The architecture was intended to cover all the TCs. See the 3rd bullet on the 1st slide. I really don't want 6 testing architectures. I want the TCs to collaborate and share as much as possible. We need to position ourselves to take advantage of economies of scale.

I hope that clarifies.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Anish Karmarkar ---11/21/2008 09:20:10 PM---Dave, Thanks for sending this out.

From:	Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:	sca-j@lists.oasis-open.org
Date:	11/21/2008 09:20 PM
Subject:	Re: [sca-j] testing architecture

---

Dave,

Thanks for sending this out.
I certainly agree with the 1st slide.
On the 2nd slide (as well as in the whiteboard picture), it shows two 
runtimes (in the whiteboard picture, it shows two runtimes from two 
different vendors). Since I wasn't present for the testing discussion, I 
may not be interpreting this correctly, but why do we necessarily need 
two runtimes for testing?

To pass our exit criteria [1], we need to have at least two independent 
implementations. But I don't see that we necessarily need to have two 
runtimes for all of our tests.

For example, a very simple test would be an echo/ping consisting of two 
Java components (with PBV and deployed locally) A and B with B's ref 
connected to A's service. The logic of B could consist of invoking A's 
service and println-ing the return value into some stream that could be 
directed to stdio/file.

For binding test, it can get tricky because we have to capture messages 
on the wire and ensure that it did the Right Thing, and every 
implementation may not provide access to the messages, possibly 
requiring two runtimes. But for non-binding tests we don't need that. 
Furthermore, even for binding tests, we *may* be able to get away with a 
single implementation by using utilities like tcpmon and setting the 
URLs to facilitate redirecting/forwarding.

I hope I haven't completely misinterpreted the slides.

-Anish
--

[1] http://www.oasis-open.org/committees/sca-j/charter.php


David Booz wrote:
> Ashok asked me to recap my testing thoughts and the picture, and put 
> them onto some slides. Some of these thoughts come from Mike E also, so 
> I don't want mis-represent where they are coming from. I'm happy to add 
> more material (there's only two slides here) as we progress with the 
> discussion and clarify the ideas. The last slide in this deck is meant 
> to be equivalent to the white board picture that Mark C captured in a 
> photo and sent to the list.
> 
> /(See attached file: testing-design.ppt)/
> 
> 
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php