RE: TRP Work Plan - Version 17 Aug 00

[richard drummond <rvd2@worldnet.att.net>]

that was the discussion in our meeting after you started the tpa group.
there was confussion on the name "service-interface". it is not currently
clear how the business-interface fits into the messaging system. it is clear
how the message-service-interface works -- and api with real-time
interrupts.

I would see them working together in the following manner... a business
process has been defined in xml in some manner (schema or dtd .. derived
from xmi). when the session-setup-system setups the messaging/application
session it may use an api to caputure the choreograph and set the
choreograph via the messaging-service-interface into the messaging system or
the application support system. I personnal do not believe the choregraph
belongs in the messaging system but should be in the application support
layer.

so lets call them messaging-service-interface, choreograph-service-interface
and process-service-interface.... maybe this clear up the confussion...
because the word service interface is confussion to me... best regards, rik



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


Let's be careful.  We have two service interfaces at the moment:

   The interface between the message service and the business process which
   couples the two specifications together.
   <ServiceInterface> in the message header.  This is the logical interface
   to one partner's business process which is seen by the other partner.

I suggest choosing a different term for one of them, probably the
inter-layer interface (1), since that doesn't have a definition yet.

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



richard drummond <rvd2@worldnet.att.net> on 08/19/2000 05:27:52 AM

To:   Nicholas Kassem <Nick.Kassem@eng.sun.com>, gvh@progress.com, David
      Burdett <david.burdett@commerceone.com>
cc:   "'Jim Hughes'" <jfh@fs.fujitsu.com>, ebxml transport
      <ebxml-transport@lists.ebxml.org>
Subject:  RE: TRP Work Plan - Version 17 Aug 00



we have been calling it service interface.

-----Original Message-----
From: Nicholas Kassem [mailto:Nick.Kassem@eng.sun.com]
Sent: Friday, August 18, 2000 7:10 PM
To: gvh@progress.com; David Burdett
Cc: 'Jim Hughes'; ebxml transport
Subject: Re: TRP Work Plan - Version 17 Aug 00


Could we loose the term API since it's such an overloaded term?

Nick

At 03:53 PM 8/18/2000 -0700, Gordon van Huizen wrote:
>Ah. Trigger finger on my part. I'll blame it on a bad headache today.
>
>-gvh-
>
>David Burdett wrote:
> >
> > Gordon
> >
> > I'm just arguing that we put the service interface in a separate
document.
> > That's all.
> >
> > David
> >
> > -----Original Message-----
> > From: Gordon van Huizen [mailto:gvanhuiz@progress.com]
> > Sent: Friday, August 18, 2000 1:35 PM
> > To: David Burdett
> > Cc: 'Jim Hughes'; ebxml transport
> > Subject: Re: TRP Work Plan - Version 17 Aug 00
> >
> > A counter argument:
> >
> > We have done nothing, to date, to specify higher-level messaging system
> > semantics (batching, application-level acknowledgements--distinct from
> > replies, error handling, etc.). I don't see how we can possibly
validate
> > the specification without having drilled into this. I believe we need
to
> > have a concrete idea of what the service level semantics are as they
> > relate to the application. This doesn't mean that we need to develop an
> > "API", which is where I think most people get stuck.
> >
> > -gvh-
> >
> > David Burdett wrote:
> > >
> > > 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
>begin:vcard
>n:Van Huizen;Gordon
>tel;work:510-848-1988
>x-mozilla-html:TRUE
>url:http://www.sonicmq.com
>org:Progress Software;XML and Internet Technology
>adr:;;14 Oak Park;Bedford;MA;01730;
>version:2.1
>email;internet:gvh@progress.com
>title:Director, Product Management
>fn:Gordon Van Huizen
>end:vcard