RE: TRP Work Plan - Version 17 Aug 00

[David Burdett <david.burdett@commerceone.com>]

Henry

We have from the requirements and overview document ...
>>>
1) Servers/systems that support the exchange of documents shall be treated
as "black boxes"  
2) The method used to transport documents shall be completely independent
of:
  a) the hardware used by the server/services at each end 
  b) the software or systems architecture of the server/services at each the
language used for implementation of systems and applications.
<<<

I think these requirements imply that one party need have no knowledge of
the technology used by the other party. In turn this means that:
1. A party must be able to discover *everything* they *need* to know just
from the message, and therefore
2. We must write the ebXML Messaging Services spec so that they can ignore
the service interface spec **if** they want to.

Please understand, that I think a service interface spec will be a very
useful thing to have (in fact we wrote one for IOTP). I'm just arguing that:
1. The ebXML Messaging Services Spec should not have to rely on it
2. Implementers don't have to built to it if they don't want to.

David


-----Original Message-----
From: Henry Lowe [mailto:hlowe@omg.org]
Sent: Tuesday, August 22, 2000 1:40 PM
To: David Burdett
Cc: 'gvh@progress.com'; 'mwsachs@us.ibm.com'; 'Jim Hughes'; ebxml
transport
Subject: RE: TRP Work Plan - Version 17 Aug 00


David,

You are stating a goal for our Headers here.  Did we ever agree 
to this goal, i.e., all info necessary for message exchange be 
contained in the Header?  I'm not saying this is a bad goal, but 
if we are not all singing from the same book, we may not agree. 


I believe Gordon pictures some additional info being conveyed 
in the parameters of the API, be it real of conceptual.  Personally, 
I rather like this goal as it severly constrains the API parameters 
to be trivial.

Henry
-------------------------------------------
At 12:50 PM 08/22/2000 -0700, David Burdett wrote:
>Gordon
>
>I agree that awareness of the Interface is a benefit. I disagree that
>"implementations of the wire protocol will require semantic knowledge that
>is not imparted stricly from the fields in the header".
>
>If we can't fully define, in our spec, the meaning or semantics behind ...
>1. each field in the header
>2. the meanings implied when these fields occur in combination within a
>header
>3. the meanings implied when messages (e.g. a normal message and it's ack)
>are received in a specific sequence
>
>... then, IMO, we are not doing our job properly.
>
>If we REQUIRE that particular type of interface is used to make an ebXML
>Messaging Service Spec work, then we are creating an additional barrier to
>its use.
>
>David
>
>-----Original Message-----
>From: Gordon van Huizen [mailto:gvanhuiz@progress.com]
>Sent: Tuesday, August 22, 2000 4:07 AM
>To: David Burdett
>Cc: 'mwsachs@us.ibm.com'; 'Jim Hughes'; ebxml transport
>Subject: Re: TRP Work Plan - Version 17 Aug 00
>
>
>
>
>David Burdett wrote:
>> I think it should be possible for two parties communicating using the TRP
>> spec to achieve COMPLETE interoperability without implementing ANY of the
>> Interface spec - i.e. conformance to the wire protocol alone should
>suffice.
>> Do you agree?
>
>My assertion would be that successfully achieving interoperable
>implementations of the wire protocol will require semantic knowledge
>that is not imparted stricly from the fields in the header themselves
>and can benefit from awareness of the Interface. But that's just a
>hunch, since we aren't "there" yet. Regardless, the two levels must be
>kept in synch for a developer to stand a chance of implementation, as
>well as for us to actually get the spec work done. Witness the deltas
>that are appearing elsewhere.
>
>-gvh-