RE: Test Indicator Issue

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Chris,

	I think that there is a third option which is, BTW, the one I support:

3 - Do not use a Test Indicator at all

I am confused by the discussion in this thread. I think that the ide from Dick
of using a Test environment and a Production environment (pls correct me if
I oversimplify) exchnaging messages that are "neutral" to the execution 
environment where they are actually exchanged is :
	- the most simple to implement
	  (the test environment contains "test data" including, eventually,
	  "test URLs" which should be answered as part of the responses)
	- the most resilient to changes
	- the most "clean". In fact :
		a.	If the "test" flag should be interpreted by the MSH ONLY
			then the MSH should be "aware" of application semantic
			(at least, forward the payload to this or that...) and,
			thus, may be more difficult to build (or to buy).
			If the "context" in which this flag is used is the one
			of pinging, than I still think that a "PING" type of
			message is better suited.
		b.	if the "test" flag is forwarded to the application layer
			together with the payload and no behaviour is specified
			then there is the risk of lack of interoperability across
			partners that do not share the same semantic for interpreting
			the flag (in some way, each partner should declare in its own
			CPP how it would eventually deal with the "test flag")

So, I concur with who said that this discussion could introduce ripple
effects in other specs.

In summary, I honestly think that this topic is about properly managing test
and production environments and not about the semantic of the message and of the
associated layers.

/Stefano


> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Monday, November 27, 2000 6:52 PM
> To: Miller, Robert (GXS)
> Cc: ebxml-transport@lists.ebxml.org
> Subject: Re: Test Indicator Issue
> 
> 
> I'm getting the sense that there seems to be some
> consensus on the need for a test indicator, but that
> the scope of its use/intent seems to be at issue.
> 
> 	1 - MSH only (MUST NOT pass message to "application")
> 	2 - undefined (MSH MAY pass message to "application"
> 		along with test indicator and allow application
> 		to figure out what to do)
> 
> Have I captured this sense correctly?
> 
> Can we agree to have the vote on this aspect?
> 
> Cheers,
> 
> Chris
> 
> "Miller, Robert (GXS)" wrote:
> > 
> > Dick,
> > 
> > The tables which select the URL to which to deliver the 
> payloads, whether
> > these tables be in the application code on in some middleware, 
> would have to
> > differ between the production system and the test system.  And 
> there might
> > be dozens of URL's each of which needs both a production and a 
> development
> > entry.  And the tables might be stored in the same database as 
> other tables,
> > so when a database is copied from prodcution to test, the 
> changes have to be
> > re-introduced.
> > 
> > Cheers,
> >         Bob
> > 
> > -----Original Message-----
> > From: Dick Brooks [mailto:dick@8760.com]
> > Sent: Monday, November 27, 2000 9:56 AM
> > To: Miller, Robert (GXS); Nikola Stojanovic;
> > ebxml-transport@lists.ebxml.org
> > Subject: RE: Test Indicator Issue
> > 
> > Bob,
> > 
> > I don't understand how separate test/production URL's does the 
> following:
> > 
> > > referenced below.  But I contend that these other ways reduce the
> > > parallelism of the test system to a greater extent than does 
> a test flag.
> > 
> > Please explain. Thanks.
> > 
> > Dick Brooks
> > Group 8760
> > 110 12th Street North
> > Birmingham, AL 35203
> > dick@8760.com
> > 205-250-8053
> > Fax: 205-250-8057
> > http://www.8760.com/
> > 
> > InsideAgent - Empowering e-commerce solutions
> > 
> > > -----Original Message-----
> > > From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
> > > Sent: Monday, November 27, 2000 9:23 AM
> > > To: Nikola Stojanovic; ebxml-transport@lists.ebxml.org
> > > Subject: RE: Test Indicator Issue
> > >
> > >
> > > List-Unsubscribe:
> > >  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> > > List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> > > List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
> > >  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
> > >
> > > Yes there are other ways to indicate a 'test' message, two of 
> which are
> > > referenced below.  But I contend that these other ways reduce the
> > > parallelism of the test system to a greater extent than does 
> a test flag.
> > > Use of a test flag is a proven practice. So my advice is add the
> > > test flag -
> > > "If it ain't broke, don't fix it!"
> > >
> > > Cheers,
> > >        Bob Miller
> > >
> > > -----Original Message-----
> > > From: Nikola Stojanovic [mailto:nhomest1@twcny.rr.com]
> > > Sent: Monday, November 27, 2000 8:57 AM
> > > To: ebxml-transport@lists.ebxml.org
> > > Subject: Re: First issue [was: Outstanding Issues - LONG please red to
> > > end}
> > >
> > >
> > > <Dick Brooks>
> > > There are others means to indicate a "test" versus 
> "production" message
> > > exchange. For example:
> > > - separate production and test ebxml handler URL's 
> (mailboxes, FTP sites,
> > > etc.)
> > > - separate production and test Party ID's
> > > </Dick Brooks>
> > >
> > > Makes sense. I agree.
> > >
> > > Nikola
> > >
>