RE: TRP Work Plan - Version 17 Aug 00

[mwsachs@us.ibm.com]

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