RE: Trading Partner Logical Identification based on EDIFACT or X12qualifiers

[David RR Webber <Gnosis_@compuserve.com>]

Message text written by INTERNET:dick@8760.com
>

I'm hoping your answers will provide everyone a better understanding of the
issue.
<<<<<<<<<<<<<<<<<<<

Dick,

OK - good points.  This is definately all tied into the approach doc's I'm
focusing on doing next.

I occasionally get frustrated at the lack of shared memory space!  Thanks
for taking me to task on that - but I will get to detailing a chunk of
that.

Here's one scenario for people to think about taken from the BizTalk
model that M$ promoted last year:

1) Two BT servers exchanging messages - super secure, encrypted,
     authenticated, and BT servers keep persistent information locally.
     Message queues allow complete tracking of BP flow too.

2) One BT server taking an internet transaction from a 3rd party, and
     passing that to another BT server.  As in 1) above the second BT
     server treats the other BT as a trusted source, so how can it know
     the information came from an untrusted source?   Because the
     bulk of the interchange information is in the local persistent store,
     not the message headers, there is no audit trail exposed.

That's just one domain problem - and there are obviously many
more - that ebXML should clearly demonstrate a solution where
earlier methods such as BT do not show clear defined auditing.

It's tackling such deceptively simple and recurrent themes that
we need to go after and understand the tools we are providing
to address the business needs and legal requirements.

Remember that fraud or disruptive attacks will always attempt to 
use the least secure environment to compromise the most
secure environment, and that risk of exposure or discovery
is the best safe guard.

We need to provide people robust tools that work because of
the inherent design, and not despite it!  In other words, by
skillfully designing the way the pieces work we can provide
people implicitly with a better solution.  That's why an airbag
is in your car, even if you choose not to put your seat belt on....

The repository layer should also be something that provides
seamless and unintrusive functionality that the end users are
not even aware of at one level, but that auditors and systems
administrators can use to manage communications when
needed.

I think this is REALLY what people are saying when they
don't want the repository to be mandated.

In other words people want their cake and eat it!!!

We shall see how this plays out once we have concrete
details on the table on the interaction models and 
associated repository support.

DW.