RE: TRP Work Plan - Version 17 Aug 00

[mwsachs@us.ibm.com]

Rik,

You have hit the problem right on the nose.  We have not been at all
focussing on the need for an application support layer and I suspect that
BP may not have been doing that either.  There are things that a decent
run-time should supply to support the application.  While they are outside
the messaging service architecture, they are most likely embedded in the
run-time implementation of the messaging service.

In the IBM Research prototype runtime (BPF), those services which are
outside the scope of the Messaging Service include

   Conversion of TPA action names to local method calls
   Checking for violations of Sequencing Rules
   Business document generation and parsing (via plug-ins)
   Security services
   Correlation of conversations (e.g. in a supply chain situation)
   Logging
   Recovery

It might be worthwhile my giving a more detailed talk on BPF (5-6 charts)
at the Tokyo meeting.  This might also expose some use cases for the TPA
constructs in the message header.  This could be scheduled within a TRP or
TP meeting, with members of TRP, TP, and BP invited.

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

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "ebxml transport" <ebxml-transport@lists.ebxml.org>
Subject:  RE: TRP Work Plan - Version 17 Aug 00



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