OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: TRP Work Plan - Version 17 Aug 00


The requirements document addresses requirements on (in this case) what
should be in the messaging service specification.  If two parties want to
communicate, they have to know everything down to the wire.  I think that
we all understand that and are finally coming to the realization that
someone has to specify the bindings between the messaging service and the
lower communication levels.

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
*************************************************************************************



David Burdett <david.burdett@commerceone.com> on 08/22/2000 05:44:04 PM

To:   "'Henry Lowe'" <hlowe@omg.org>
cc:   "'gvh@progress.com'" <gvh@progress.com>, Martin W
      Sachs/Watson/IBM@IBMUS, "'Jim Hughes'" <jfh@fs.fujitsu.com>, ebxml
      transport <ebxml-transport@lists.ebxml.org>
Subject:  RE: TRP Work Plan - Version 17 Aug 00



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-





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC