RE: Do we need to revisit the Overview & Requirements document

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

assign some one to keep it uptodate as we go.... so more like your #1 than
#2.... rik

-----Original Message-----
From: David Burdett [mailto:david.burdett@commerceone.com]
Sent: Monday, August 28, 2000 4:41 PM
To: ebXML Transport (E-mail)
Subject: RE: Do we need to revisit the Overview & Requirements document


Rik said ...

>>>the requirements doc should be adjusted as agreed upon to fit our spec
findings<<<

... I agree but what **process** do we follow to reach agreement? Two
alternatives ...

1. Ignore the O&R spec and change it retrospectively when we've finished
2. Try to follow O&R spec as closely as we can by using it to define our
scope and then change as we go along.

Which is closer to your thinking (or please suggest an alternative).

David

-----Original Message-----
From: richard drummond [mailto:rvd2@worldnet.att.net]
Sent: Monday, August 28, 2000 1:39 PM
To: ebXML Transport (E-mail)
Subject: RE: Do we need to revisit the Overview & Requirements document


the requirements doc should be adjusted as agreed upon to fit our spec
findings. it should not be considered the final say. i believe we should
have a service interface as you all well know..... but this is a group
decision.  Jim H. who has responsibilities for the requirements update?
best regards, rik

-----Original Message-----
From: David Burdett [mailto:david.burdett@commerceone.com]
Sent: Thursday, August 24, 2000 12:56 PM
To: ebXML Transport (E-mail)
Subject: FW: Do we need to revisit the Overview & Requirements document



Resending as original bounced

-----Original Message-----
From: David Burdett
Sent: Wednesday, August 23, 2000 1:42 PM
To: ebxml-transport@lists.ebxml.org
Subject: Do we need to revisit the Overview & Requirements document


Folks

I'm replying to Chris's email as a symptom of a problem that I think we
should address (so this isn't personal Chris). Basically though, I think we
have a problem of scope creep/change with the work we are trying to do. For
example Chris says in his email below ...

>>>As for the service interface between the MS and the "application", I feel
that too is outside our charter.<<<

... whether this is right or not is immaterial. The fact is we have an
Overview & Requirements spec that has been out for quite a while which
contradicts Chris's view (see figure 2 in the spec).

If we continue to allow changes, without using the Overview & Requirements
Document to guide what we do, we will get in continuous, and perhaps not
very constructive, debate about what is (or is not) in scope.

I suggest therefore that we ...
1. All review the existing Overview & Requirements document
2. Each identify changes that we would like to see (either additions or
deletions)
3. List all the suggestions in the same way as we listed changes on the
current messaging services spec
4. Agree collectively which suggestions are accepted
5. Update the Overview & Requirements document

... and then WE JUST BUILD A SOLUTION THAT MEETS THE REQUIREMENTS !!

Who thinks that this would be a sensible process for us to follow.

David

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Wednesday, August 23, 2000 11:24 AM
To: mwsachs@us.ibm.com
Cc: ebxml-transport@lists.ebxml.org
Subject: Re: Messaging Service Comment


In a way, I concur with Marty's assessment. However, it would
seem to me that rather than an "interface" definition (eg API)
that it is important that we ensure that all of the requisite
information is present, either in the headers themselves or
in the associated TPA to enable an implementation to perform
the necessary magic.

An example, the use of a "logical" To address. This must be mapped
to an appropriate URL (for HTTP), email address (for SMTP), etc.
We shouldn't need to provide an interface to a name resolution
service (such as DNS or THTTP). This is strictly implementation
detail. We shouldn't even suggest where this name resolution should
take place (within the MS or within the communication service
implementation.

It would seem to me that the appropriate place for this sort of
thing might be OMG, Apache or as a JCP JSR (JAXP?) for Java implementations.
I would expect that most providers of an ebXML TR&P MS would provide
both the MS and the CS (communication service adaptors). If someone
were to develop a standalone MS with a well defined API for the CS adaptors,
that might be a good thing, but I don't believe that it is in our
charter to do so.

The POC demos are providing us with valuable feedback as to whether
we're providing all of the requisite bits in the headers and/or TPA
such that a provider can effectively develop an interoperable
implementation. I think that thus far, we're on track in that regard.
If not, then we must work with them to understand what their perceived
needs are and figure out how they can and should be mapped to either
the headers or the TPA.

As for the service interface between the MS and the "application",
I feel that too is outside our charter. Yes, it would be a good thing
if there were a standard by which all MS implementations were developed,
but again, OMG, Apache or elsewhere would seem to me to be a more suitable
choice for this manner of standards development.

Possibly, we should be working with one of these (or other) organizations
towards
this end. However, let's not lose sight of the prime objective here.
The interoperability we seek with ebXML is focused on inter-enterprise
interoperability. This is acheived by defining the headers and the TPA,
not a set of APIs which would allow for an enterprise to exchange
implementations
without having to do much in the way of reengineering. YES, that is a good
thing to have (eventually) but it is NOT a requirement for enabling
interoperable exchange of messages between enterprises, small or large.

My $0.02,

Chris

mwsachs@us.ibm.com wrote:
>
> Again, sorry about the deadline.  This comment belongs on the work list,
> not as a correction to the current version.
>
> Some of the dicussions about interrelations between Reliable Messaging and
> transport protocols point up the need to state the assumptions about the
> transport function in some manner.  One possibility is some kind of
> definition of a conceptual interface between the Messaging Service and the
> transport function.  It's fine to say that the messaging service is
> agnostic to the transport protocol but in real life, the Messaging Service
> run-time must interact with the transport run-time. Design of the
messaging
> service protocol must be with the understanding of what goes on in the
most
> likely transports.
>
> Since it is highly likely that an implementation will include both the
> messaging service and the transport function, it may be sufficient to
> express the interactions as a series of informative notes (or an
> informative appendix) rather than as a formal interface definition. The
> important point is that the assumptions have to be stated to ensure that
> the messaging service and transport function will work together correctly.
>
> 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
>
****************************************************************************
*********

--
    _/_/_/_/ _/    _/ _/    _/ 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