RE: TRP Work Plan - Version 17 Aug 00

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

Comments inline. Actually contrary to your opening comment, I actually think
we are in completely on the same page.

David
PS Also copied this to the TRP list.

-----Original Message-----
From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, August 22, 2000 7:43 AM
To: David Burdett
Subject: RE: TRP Work Plan - Version 17 Aug 00


David,

I don't think we are quite on the same page.  The conceptual interface we
are discussing is between adjacent layers (BP and Messaging Service) at the
same party.  If we do our jobs right, that interface is invisible to the
parties communicating at the BP level via the messaging service.  
>>> I agree<<<

The interface we are talking about is NOT an API by which applications can
communicate while bypassing the BP layer.  That's why we don't want to
define it as if it were an API.
>>>I also agree. The interface definition will be useful. We just need some
language neutral way of defining the interface.<<<

I absolutely agree with you that an implementation does not have to
implement a visible interface between the layers.  The main reason for the
conceptual interface is to ensure that the designers of the protocols have
a common understanding of what goes on in the adjacent layers so the layers
interact as desired.
>>>I think this is a good idea<<<

There is some logistical advantage to us in keeping the conceptual
interface in our document as an informative appendix, namely that we don't
lose sight of it.  
>>>I'm fairly comfortable with this idea as long as it is clearly stated as
non-normative. However we might then lose the benefit of having standard
bindings (e.g. for Java, C++, CORBA) that confrom to the interface.<<<

I suppose it could be argued that it belongs in the BP
specification but since some of us have noticed the need for it, it might
make sense to just put it in ours and be done with it.  
>>>I have always thought that we should do it since we (probably) understand
the problem space better.<<<

Of course, while it
is a work in progress, the interface might well start as a separate
document, just as we are doing with reliable messaging.

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/21/2000 07:08:45 PM

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



>>>I can't agree with the argument that the interface definition will
increase the complexity of management of the specification.<<<

That isn't my main reason for keeping the interface definition spec
separate.

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?

If this is true, then implementation of the Interface spec is purely
optional and therefore an implementer MAY choose to ignore it. Thererofe it
should be in a separate spec.

David

-----Original Message-----
From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
Sent: Sunday, August 20, 2000 7:31 PM
To: David Burdett
Cc: 'Jim Hughes'; ebxml transport
Subject: RE: TRP Work Plan - Version 17 Aug 00


Dave,

We definitely should not define a real API between the messaging service
and the layer above for precisely the implementation reason you state.
However at the moment, we have no definition at all of how the two layers
interact, which is causing confusion for all of us.

Standards such as Fibre Channel and, I believe, some of the communication
protocols which are formulated as multiple layers, have conceptual service
interfaces between layers which are not specific to a programming language
but clearly show (in abstract terms) the functions that have to be
implemented for the two layers to communicate.  At the same time, people
understand that in tight implementations involving multiple layers, there
may well be no detectable embodiment of that interface.

Having such an interface will help us all to communicate, especially across
teams, and will help avoid the temptation to add things to the message
header which belong in an interlayer interface.

I can't agree with the argument that the interface definition will increase
the complexity of management of the specification.  Having multiple layers
in different specifications (e.g. BP and TRP) is what causes the
complexity.  A conceptual service interface can help to bring order out of
chaos.  The Fibre Channel group believed that they could solve the problem
by putting all the layers in one book but they ended up formulating the
interfaces anyway.

By the way, in Fibre Channel, those conceptual service interface
definitions are labeled "informative" to make it clear that they don't
intend to step on any implementers' toes.

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/18/2000 03:58:16 PM

To:   "'Jim Hughes'" <jfh@fs.fujitsu.com>, ebxml transport
      <ebxml-transport@lists.ebxml.org>
cc:
Subject:  RE: TRP Work Plan - Version 17 Aug 00



Jim

I firmly beleive we *don't* put the Service API spec into the messaging
spec
but should instead keep it as a separate document. The reasons are:
1. The API's you use to interface with the ebXML Messaging Service is
purely
an implementation decision. If, for example you wanted to put the service
on
a PDA then compliance with the Service Interface could be too burdensome
2. More importantly conformance to the API is not required for
interoperability between trading partners. All that is needed is compliance
with the wire protocol
3. It will make it harder to maintain and revise the document as the editor
role will become a bottleneck
4. There is a requirement in the Overview & Requirements document that says
...

     "1) Servers/systems that support the exchange of documents shall be
treated as "black boxes"  "

We definitely do need the spec as it will make it easier for business
process (i.e. application) implementers to do plug-and-play with ebXML
services from different vendors.

David


-----Original Message-----
From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
Sent: Thursday, August 17, 2000 2:27 PM
To: ebxml transport
Subject: TRP Work Plan - Version 17 Aug 00


Based on comments from the TRP meeting this morning and several email
messages, here is a new cut of the plan.

Significant changes:

- added Service API to the plan. I believe the first version must be folded
into the overall Messaging Services Spec within the month, and some amount
of the Service API should be approved in Tokyo.

- I have indicated where we should release the Messaging Spec, the Service
API drafts and the Messaging Spec to the POC.

Other notes:

- as before, I've made some assumptions about the Security work, so I need
confirmation of these dates...

- I arbitrarily assigned major version numbers to the Messaging Services
Spec (based on approval at plenary meetings) and showed how the subordinate
specs are being folded into it.

- I reduced the chart scope to just the Vancouver meeting so it prints
better. We don't know what we're doing between Vancouver and Vienna just
yet...!

- 5 days is shown for Quality Team review, with two-week Member reviews
immediately following. We may need some time inserted to react to Quality
Team comments...

And apologies to Rik/Chris, as they haven't yet approved/commented on the
work plan. I trust they will concur in our planning work during their
absence!

Jim