Re: DRAFT TRP Work Plan

[Gordon van Huizen <gvanhuiz@progress.com>]

Are we talking about transport bindings here? I thought we had agreed in
San Jose that these should be in the spec, at least as an appendix. I
agree with David that the work needs to be done, whether it's documented
or not, to ensure that the rest of the spec provides suffieient support
for the real transports that will be used. I would think that including
documentation of the bindings, without necessarily being prescriptive,
would be useful for developers to see how artifacts in the spec map to
implementations over the various transports.

I'm optimistic that the spec can contain enough detail that
implementations can occur against the targeted protocols, but we need to
at least think through real world implementations to be sure. This is
particularly important for reliable messaging over anything but
MQSeries.

-gvh-

David Burdett wrote:
> 
> Jim
> 
> Enabling other protocols to bridge to ebXML is not part of the spec it's an
> activity. In outline what we need to do is:
> 1. Agree other protocols to review
> 2. Analyze those protocols to identify gaps which would prevent their
> functionality being supported and identify/suggest changes to the spec that
> need to be made
> 3. Make the changes to the spec.
> 
> What prompted me to add this activity is that IOTP will, I think, need
> synchronous communication and the current ebXML TRP spec doesn't support
> this.
> 
> Regards
> 
> David
> 
> -----Original Message-----
> From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
> Sent: Thursday, August 17, 2000 2:19 PM
> To: ebxml transport
> Subject: Re: DRAFT TRP Work Plan
> 
> Rather than overload the Gantt chart with details (I think tracking at the
> major function level is enough), these ideas should be inserted into the
> draft document as placeholders (as Gordon suggests in his next message),
> and then someone assigned to come up with a draft by a certain date that is
> targeted to be inserted into a projected version of the Messaging Spec.
> 
> I did put in a separate line item for the Service API because I think it is
> a gaping hole.
> 
> Jim
> 
> At 10:31 AM 8/17/00 -0700, Gordon van Huizen wrote:
> >I would also add (and this overlaps I believe with 2 & 3): Transport
> >Bindings. The first thing to do would be enumerate the transports for
> >which bindings will be specificed (HTTP, FTP, SMTP, MQ?).
> >
> >-gvh-
> >
> >David Burdett wrote:
> > >
> > > Jim
> > >
> > > There are a number of work items that I think we need to add to the
> plan.
> > >
> > > 1. The creation of a service interface (API) specification for how
> > > applications can interact with an ebXML Messaging Service (we discussed
> > this
> > > today on the call).
> > > 2. Support for other messaging protocols. One of our objectives is: "4)
> to
> > > enable existing "messaging" solutions to "bridge" to the ebXML
> solution".
> > > 3. Development of how our protocols work synchronously. Specifically how
> > > ebXML can work where an HTTP client is talking to an HTTP server. This
> > would
> > > be required, for example to support the way the Internet Trading
> Protocol
> > > Works.
> > >
> > > David
> > >
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