RE: TRP Work Plan - Version 17 Aug 00

[Henry Lowe <hlowe@omg.org>]

David,

I'd suggest CORBA -- done by OMG.  

Of course, at this point, I can't promise anything as 
OMG does what the membership, or at least some subset 
of the membership, think is of value and provide the 
technical resources to do.

Best regards,
Henry
--------------------------------------------------
At 12:49 PM 08/25/2000 -0700, David Burdett wrote:
>We also need to do more than just RosettaNet. My initial candidate list (and
>suggested responsibilities) would be:
>
>* AS1/AS2 - Dick Brooks?
>* IOTP - David Burdett
>* RosettaNet - Prasad Yendluri?
>* MQ Series - John Ibbotson?
>
>Any more standards we should consider?
>
>David
>
>
>-----Original Message-----
>From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
>Sent: Friday, August 25, 2000 7:07 AM
>To: David Burdett
>Cc: 'Jim Hughes'; ebxml transport
>Subject: Re: TRP Work Plan - Version 17 Aug 00
>
>
>I agree. We should see if we can't get the RNIF mapping
>out of the POC team. Prasad and others basically performed
>this function for purposes of the SJ demo. It would be 
>a useful, (non?-)normative appendix IMHO.
>
>Chris
>
>David Burdett wrote:
>> 
>> Jim
>> 
>> ... in an earlier email I suggested we added a comparison with existing
>> protocols (RosettaNet, IOTP, AS1/AS2) ... as a separate work activity. I'm
>> not sure we resolved this. I think we need to add it as a separate
>activity
>> since:
>> 1. We need to do this work to meet our requirements
>> 2. It is a significant piece of work, so I don't want us to forget it
>> 
>> David
>> 
>> -----Original Message-----
>> From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
>> Sent: Monday, August 21, 2000 10:11 AM
>> To: ebxml transport
>> Subject: RE: TRP Work Plan - Version 17 Aug 00
>> 
>> My reasons for adding it to the Work Plan as I did was:
>> 
>> - simplicity
>> - there may be vendors which will create Messaging Services, and these
>> Services need to be interoperable with respect to higher layer business
>> processes
>> 
>> But I don't care about the packaging decision, as long as someone gets
>> going on getting this interface decided for the POC and we look towards a
>> final solution. Rik/Chris, how do you want to lead this resolution?
>> 
>> Jim
>> 
>> At 12:58 PM 8/18/00 -0700, 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
>
>-- 
>    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
>   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
>  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
>       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
>_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903