RE: ebXML development dependencies and TPAs

[Scott Hinkelman/Austin/IBM <srh@us.ibm.com>]

------David-------------
Scott/Marty
I'm not sure of the benefit of developing tpaUML now as I think it is too
soon and will need to change because of dependencies on other work we do.

My
take on thes dependencies are as follows ...
1. Two parties need to know information about each another before they can
carry out ecommerce.

<SRH>Agreed. In my mind, from a "least known about you" senario, the
party doing the discovery must at least know the taxonomy of the Registry,
and the set of applicable constraints for search.

2. The information they need to know is, at least partly, dependent on the
specifications that ebXML is developing especially for TRP and BP.

<SRH>Agreed. More so Registry interface and the domain/usage taxonomy.
BP representation fits in a taxonomy. We need to insure the bootstrap
TRP usage works in contacting the Registry. This is likely to imply
a fixed mandatory set of both technology parameters and a fixed Business
Process for baseline discovery of Registry characteristics, like a
Taxonomy name, etc.

3. The information contained in the TPA is dependent on the information
that needs to be shared.

<SRH>Agreed also.

So I conclude that we can't define what goes in a TPA until we have gone
much further in defining our specs.

Does this argument make sense? Am I missing something?
If my argument makes sense we should focus on our ebXML specs first since
it is the first dependency.

<SRH>Your earlier use case work was right on. We need to elaborate
on those to address increasing detail that discusses a base Registry
interface that allows discovery of things about the Registry itself;
which all Registries must support. And, how a bare TRP structure
is used to support contact of that interface. This can be done with
XML or UML to reflect the increased details expanding the current
*come to an agreement* use cases,which will indeed answer
many questions on what goes where in a negotiated agreement.

It has always seemed working at a logical level (UML) level is more
natural in order to get the relationships correct, rather than initially
working
at the XML physical level; even with the model mis-matches between both
worlds.
We are seeing more domain groups initially start out working directly
at the XML level with XML DTD authoring tools, and eventually move to UML.
This is not without other considerations with mapping to XML, and the whole
XMI world, which I will not go into here. But there is much work going on
in this space, and we see trends as I stated. I think logical modeling
in UML with focus on use case will be beneficial.

------------------------------------

Scott Hinkelman
Senior Software Engineer, IBM Austin
Emerging Technologies, SWG
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



john_ibbotson@uk.ibm.com on 09/06/2000 04:48:57 AM

To:   ebxml-transport@lists.ebxml.org
cc:
Subject:  RE: ebXML development dependencies and TPAs






I agree that doing both in parallel is the best plan. Both teams can then
test the assumptions made by the other.
For now, the TPA representation in UML will be the best appoach since it
allows us to concentrate on the contents of a TPA rather than get bogged
down in religious debates on XML syntax. Once the model is agreed then an
XML rendering is trivial.
John

MQSeries Technical Strategy & Planning,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: +44 (0)1962 815188
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com


richard drummond <rvd2@worldnet.att.net> on 09/06/2000 02:31:27 AM

Please respond to richard drummond <rvd2@worldnet.att.net>

To:
cc:   ebxml-transport@lists.ebxml.org (bcc: John Ibbotson/UK/IBM)
Subject:  RE: ebXML development dependencies and TPAs




my take would be to do them in parallel, by having marty and scott list the
parameters they think each team needs in the tpa. that way we can easily
determine where the over lap is... how about that for a solution?   rik

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Tuesday, September 05, 2000 8:11 PM
To: 'Martin W Sachs/Watson/IBM'
Cc: ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
Subject: RE: ebXML development dependencies and TPAs


I agree as long as we recognize that there may be significant re-work. It's
all really a question of balance. You want to make progress, but you don't
want to have to re-do work because of other dependencies.

David

-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, September 05, 2000 3:44 PM
To: Burdett, David
Cc: ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
Subject: Re: ebXML development dependencies and TPAs



David,

On the other hand, thinking about what goes in the TPA may provide insight
as to what belongs in the messaging service specification and its upper and
lower interfaces.  Doing the messaging service and TPA in parallel should
provide useful feedback between the two teams.

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 09/05/2000 06:13:34 PM

To:   ebxml-transport@lists.ebxml.org
cc:
Subject:  ebXML development dependencies and TPAs



Scott/Marty

I'm not sure of the benefit of developing tpaUML now as I think it is too
soon and will need to change because of dependencies on other work we do.
My
take on thes dependencies are as follows ...

1. Two parties need to know information about each another before they can
carry out ecommerce.
2. The information they need to know is, at least partly, dependent on the
specifications that ebXML is developing especially for TRP and BP.
3. The information contained in the TPA is dependent on the information
that
needs to be shared.

So I conclude that we can't define what goes in a TPA until we have gone
much further in defining our specs.

Does this argument make sense? Am I missing something?

If my argument makes sense we should focus on our ebXML specs first since
it
is the first dependency.

David

-----Original Message-----
From: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
Sent: Wednesday, August 30, 2000 11:52 AM
To: ebxml-transport@lists.ebxml.org
Subject: Re: representation of interfaces to the messaging service


Now that this is going to happen in UML, beware that we are beginning work
in the
BP team to integrate *tpaUML* (the UML rendering for tpaML) with the BP UML
MetaModel.
TPA spans both MS and BP, and the MS UML effort must address TPA in the
model.
The tpaUML submission is available upon request (since the internal web
pages
are apparently hosed). The submission package is 2.5 MB, and does not
require
Rational Rose to view it.

Thanks,
Scott Hinkelman
Senior Software Engineer, IBM Austin
Emerging Technologies, SWG
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Henry Lowe <hlowe@omg.org> on 08/30/2000 01:25:08 PM

To:   ebxml-transport@lists.ebxml.org
cc:
Subject:  Re: representation of interfaces to the messaging service



Gordon,

Yes, I remember you volunteered for a strawman UML service interface.
I'm 100% for it.

Henry
-------------------------------------
At 08:47 AM 08/30/2000 -0700, Gordon van Huizen wrote:
>Hi Henry,
>
>The current plan is to develop the service interface in UML. I'm hoping
>to provide a strawman service interface at the Dallas face-to-face,
>unless tomorrow's con call results in a revised plan or orientation for
>developing the interface portion of the spec.
>
>The discussions regarding layering are useful, though, toward the goal
>of a cleanly defined interface with well understood factoring of the
>service interface and transport issues.
>
>-gvh-
>
>Henry Lowe wrote:
>>
>> Marty,
>>
>> As a former OSI type, this is the sort of think I was thinking
>> of when I mentioned the use of a conceptual interface (I/F).
>> However,
>> 1. you need to add parameters to the primitives (afraid I'd have
>>    to look at an old document to see exactly how we used to do it,
>>    and
>> 2. this notation only deals with events which involved a protocol
>>    exchange, i.e., it doesn't cover (what we used to call "local")
>>    events which don't cause protocol to be sent or result from
>>    protocol being received.
>>
>> Item 2 would have to be dealt with for ebXML, IMHO.  It is usable,
>> however, and can be extended to cover local events where necessary.
>>
>> Rather than start using the OSI approach (which after all, has its
>> origins in the late 1970's), I would support your second suggestion
>> of using UML as it's richer (and also being used by the BP folk as
>> I understand).
>>
>> Best regards,
>> Henry
>> ------------------------------------------
>> At 10:21 AM 08/30/2000 -0400, mwsachs@us.ibm.com wrote:
>> >There is an inter-layer interface representation that some standards
use,
>> >which I have seen referred to as the OSI interface model. It is
considered
>> >to be technology and implementation independent and definitely won't be
>> >confused with an API. It is expressed in natural language.
>> >
>> >Consider a 2-layer structure, TOP and BOTTOM.  The conceptual interface
>> >between the TOP and BOTTOM is expressed in terms of four primitives:
>> >
>> >   Request:  TOP makes a request to BOTTOM for a specified service.
>> >   Indication:  BOTTOM sends a particular signal to TOP
>> >   Response:  TOP sends the results of the previous Indication to
BOTTOM.
>> >   Confirm:  BOTTOM conveys the results of one or more service requests
to
>> >   TOP.
>> >
>> >The specific request, etc. and the name of the "sending" level are
>> >concatenated to the primitive name thus: TOP_Data.Request.
>> >
>> >Text associated with the primitive specifies the characteristics of the
>> >primitive, such as when generated, effect on receipt, and status.
>> >
>> >Associated with naming the primitive is a brief description of the
>> >semantics (typically one sentence).
>> >
>> >Examples of this are in the ANSI Fibre Channel Physical and Signaling
>> >Interface specification which I unfortunately have only on paper.
>> >
>> >I mention this only to add to the spectrum of choice.  It is highly
likely
>> >that the BP-TRP interface will have to be in UML to mesh with the BP
meta
>> >model. This OSI interface representation is not anywhere as rich as UML
but
>> >it is a compact easily understood representation.  If we use a UML
model,
>> >we will certainly have to add the same kind of explanatory text.
>> >
>> >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
>>
>
****************************************************************************




>> >*********
>> >
>> >