OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-tp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: FW: updated requirements specification



The question that was originally raised about "service interface" is one
common usage for that term is the interface that each layer of a protocol
stack presents to the higher layer.  In this case, the term might be used
to denote the "API" that the messaging service presents to the application
layer.  That's very different than "service interface" as used in tpaML
(denotes the interface between the two business partners) and suggests that
two different terms are needed for the two interfaces.

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



"Burdett, David" <david.burdett@commerceone.com> on 10/22/2000 07:22:28 PM

To:   "'ebxml-tp@lists.ebxml.org'" <ebxml-tp@lists.ebxml.org>
cc:
Subject:  FW: updated requirements specification



Forwarding as requested

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Sunday, October 22, 2000 7:59 AM
To: Martin W Sachs/Watson/IBM
Cc: ebxml-tp@lists.ebxml.org; David Burdett
Subject: Re: updated requirements specification


Marty/David,

[please post to list, I still cannot and haven't had the
opportunity to fix my registration.]

I think that Business Service Interface and Service Interface
are one and the same. David's original suggestion to drop the
"Business" qualifier was intended to reflect the possibility
that the 'service' could be used for non-commercial purposes.

I for one have no problem in calling it the "Service Interface"
and leave it to an implementation to determine whether the
behavior being enforced is business related or simply some
set of constraints related to some uncharacterized processing
in receipt of a message.

Cheers,

Chris

Martin W Sachs/Watson/IBM wrote:
>
> In my responses to David Burdett's proposed definitions, I had one error,
> regarding "Service Interface".  Stefano is using the term "Business
Service
> Interface" to refer to a B2B implementation.  However if "Service
> Interface" is already "reserved" to refer to the API function  for the
> Messaging Service (or perhaps for any layer), the term "Business Service
> Interface" may be what we want in the CPP and CPA.  We could find another
> term for the B2B implementation.
>
> 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
>
****************************************************************************

*********
> ---------------------- Forwarded by Martin W Sachs/Watson/IBM on
10/19/2000
> 03:29 PM ---------------------------
>
> Martin W Sachs
> 10/19/2000 01:21 PM
>
> To:   "Burdett, David" <david.burdett@commerceone.com>
> cc:   ebxml-tp@lists.ebxml.org, dan@vcheq.com
> From: Martin W Sachs/Watson/IBM@IBMUS
> Subject:  RE: updated requirements specification  (Document link: Martin
W.
>       Sachs)
>
> David,
>
> The appended contains some very good suggestions.
>
> Here are my replies.
>
> Regards,
> Marty
>
> (See attached file: TP Definitions MWS Resp.doc)
>
>
****************************************************************************

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

*********
>
> "Burdett, David" <david.burdett@commerceone.com> on 10/18/2000 01:00:56
AM
>
> To:   Martin W Sachs/Watson/IBM@IBMUS, ebxml-tp@lists.ebxml.org
> cc:   dan@vcheq.com
> Subject:  RE: updated requirements specification
>
> I know that ...
> a) I raised the issue about the confusion in terminology between Party
and
> Partner, and
> b) I couldn't make the F2F to suggest that we stay with Party
> ... but the current requirements document is very wooly on definitions.
> Specifically  it says in items 3 and 4 ...
>
> >>>4.     Party. A Party is an entity such as a company, department,
> organization or individual that can generate, receive or relay Documents.
> 5.   Partner. A Partner is a Party that can engage in transactions with
> another Partner. <<<
>
> What is not defined anywhere as far as I can see is what is meant by
> "transactions". The word is used in the opening paragraph as in ...
>
> >>>a Trading Partner is an entity that engages in commercial transactions
> with other Trading Partners<<<
>
> One of the cardinal rules, IMO, of definitions is that they should be
> cumulative, i.e. you don't use a term until you have defined it. The
> current
> document is circular in that Collaborative Process uses CPA before we've
> defined it, yet CPA relies on a definition of Collaborative Protocol that
> depends on a definition of Collaborative Process.
>
> This means that the definitions should be more along the lines of the
> attached document.
>
> Thoughts?
>
> David
>
> -----Original Message-----
> From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> Sent: Tuesday, October 17, 2000 2:39 PM
> To: ebxml-tp@lists.ebxml.org
> Cc: dan@vcheq.com
> Subject: updated requirements specification
>
> Attached is our partner-requirements specification, updated per the
> discussion at last weeks Face to Face meeting (described in the minutes).
> As previously mentioned, Daniel Ling will immediately convert the format
to
> the official ebXML format and I will then begin the approval process.
>
> This does not cut off discussion but it does assure that we have this
> specification on the path to approval for the Tokyo meeting.  The results
> of discussion of this version will be applied to a later version.
>
> I have not marked the changes.  Last week's discussion resulted in many
> small changes and a few significant ones.  It needs to be reviewed in
full.
> One particular change is that the term "Trading-Partner Agreement" is
> re-introduced per the request of Klaus Naujok. A Trading-Partner
Agreement
> includes a Collaboration Protocol Agreement and higher-level business
> information.
>
> Regards,
> Marty
>
> (See attached file: partner-requirements.doc)
>
>
****************************************************************************

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

>
> *********
>
>
----------------------------------------------------------------------------

------------------------
>                                   Name: TP Definitions MWS Resp.doc
>    TP Definitions MWS Resp.doc    Type: Microsoft Word Document
(application/msword)
>                               Encoding: BASE64

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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC