RE: Test Indicator Issue

[Martin W Sachs <mwsachs@us.ibm.com>]

One reason for putting the test indicator in the message header, even if it
is an application entity, is if many applications need that indicator and
if there is something useful that the runtime can do to support it.
Putting it in a common place and supporting it with common code would be a
Good Thing.

Yes, if that indicator is an application entity, its state would have to be
passed via the conceptual interface to the messaging service.

Whether there is a test indicator or not, that conceptual interface is
needed.  I had thought that TRP already has a plan to define it.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Henry Lowe <hlowe@omg.org> on 11/28/2000 12:13:23 PM

To:   ebxml-transport@lists.ebxml.org
cc:   "Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>
Subject:  RE: Test Indicator Issue



Hi,

I haven't said much on this lately, but I can't just let this go.

What you are talking about is application stuff, not MS.  If we
have any kind layering at all (i.e., the app can't get its hands
on the MS envelope, a "test flsg" in the MS header is lost to the
app unless you have an interface (at least a conceptual one) which
defines the "test" parameter as part of the service.

In the good ole days, we used to write code where anything could
get its mitts on anything (I used to do it and I'm sure you did
too).  However, with layered systems and objects and all this
good stuff (which doesn't fit in 2K bytes -- no typo, not 2M ;-)
you can't do this anymore!! (Well, OK, you're not supposed to).

Suggestion (which can be ignored): Either put this in application
protocol or define a conceptual interface (or, call it a conceptual
service if you like :-).

Best regards,
Henry
-------------------------------------
At 10:55 AM 11/28/2000 -0500, Miller, Robert (GXS) wrote:
>Dick,
>
>Yes, DB copy is easier. And yes, a recipient could use the same database
if
>it were preloaded with dual sets of URL's/PartyIDs.  But I feel you have
>missed the point about having dual sets of URL's (or PartyID's).  Some
piece
>of software has to insert the URL into the outbound message.  The logic
>required to maintain pairs of URLs and get the right one inserted into the
>message seems inherently more complex than a simple test flag. Note also
>that testing is typically a two way street (e.g., query / response), so
both
>ends have to deal with the dual URL problem.
>
>I am aware that some EDI players choose to use separate EDI addresses
>(PartyIDs) for test purposes.  I've no idea whether they also set the test
>flag in the EDI interchange.  I certainly do not mean to exclude the use
of
>separate URLs and/or PartyIDs for those who choose to use them.
>
>Cheers,
>        Bob
>
>-----Original Message-----
>From: Dick Brooks [mailto:dick@8760.com]
>Sent: Monday, November 27, 2000 4:22 PM
>To: Miller, Robert (GXS); ebxml-transport@lists.ebxml.org
>Subject: RE: Test Indicator Issue
>
>
>Bob, see response inline:
>
>>
>> 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 production to test, the changes
>> have to be
>> re-introduced.
>>
>
>If I understand your point correctly you're saying that by having a test
>flag you're able to maintain the same data in both a test and production
>database and can easily copy data between the two, correct?
>
>If so, then I think one could say the same thing when two separate URL's
are
>used, for example:
>
>http://test.company.com/ebxmlhandler
>
>and
>
>http://production.company.com/ebxmlhandler
>
>Both URL's could share a single trading partner database instance, but use
>separate processing logic on the application payload.
>
>
>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 10:08 AM
>> To: 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>
>>
>> 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
>> >