[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Test Indicator Issue
Stefano,
The third option is always available. I agree that
Dick's proposal has merit, but as has been mentioned
more than once on the list, this feature exists in
any number of existing protcols today. Some use it, others
do not, favoring a dual environment such as Dick
has described so eloquently.
Your point is well taken. I believe that the
issue is up for a vote during tomorrow's call.
I'll vote your proxy as a 'no' to the test indicator
element and a 'yes' for the dual environment
approach suggested by Dick.
Cheers,
Chris
Stefano POGLIANI wrote:
>
> 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
> > > >
> >
--
Christopher Ferris
_/_/_/_/ _/ _/ _/ _/ Sr Staff Engineer - XTC Advanced Development
_/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063
_/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM
_/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313
_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC