[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: New work and loose ends
Dale,
my replies embedded below.
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
*************************************************************************************
Dale Moberg <dmoberg@cyclonecommerce.com> on 07/20/2001 12:13:30 PM
To: Martin W Sachs/Watson/IBM@IBMUS, Karsten Riemer
<Karsten.Riemer@sun.com>, ebxml-cppa@lists.oasis-open.org
cc: Stefano POGLIANI <stefano.pogliani@sun.com>,
chris.ferris@east.sun.com, "Riemer, Karsten"
<Karsten.Riemer@east.sun.com>
Subject: RE: New work and loose ends
I think of this issue as the Conversation Correlation Handle
problem. In other words, how does the MSH know what
conversationId to stick on a response when it just receives
a response payload from an app?
MWS: The MSH doesn't have to keep track of what conversationId to stick on
a response. This is a piece of information that should come down from the
application with the reply message payload. Of course that isn't spelled
out anywhere because the Messaging Service spec doesn't include an abstract
service interface for the MSH. The conversationId in a reply is, of
course, the same as the conversationId in the message it is replying to but
there is no reason for the MSH to keep that kind of long term state
information when the upper levels have that information.
MWS: If there is a concern about Party A understanding a conversationId
supplied by Party B, one answer is that
PartyA establishes a conversation generates a GUID as the conversationId,
maps it to whatever local handle it uses, and sends the GUID in the
message. PartyB generates a mapping of that conversationId to whatever
local handle it is using. The conversationId created by PartyA is the one
the appears in all the messages of the conversation. This approach matches
the current MSH spec, which has only one conversationId and requires it to
be unique to the two parties.
In general "notification from app"
and "submission to app"
components of a BSI are important
for MSH to "app" integration,
but I am not sure what assistance the
classical CPA and CPP provides
in easing this burden.
MWS: I am not sure whether the above paragraph is specific to
conversations or is a general statement about signalling between the MSH
and the app. I view that as a MSH service interface matter, not a CPA
matter. As to conversations in the CPA, today, the CPA doesn't deal with
conversations in a normative way (except for concurrentConversations), nor
should it. The BPSS or any other collaboration protocol will have either an
implicit or explicit abstract definition of what goes into a conversation
and it is up to the application implementation to define the conversation
boundaries and pass down begin- and end-conversation signals to the
middleware. Of course, we may run into conversation semantics issues that
do require help in the CPA but so far we haven't.
The CCH problem is possibly "flavored" by the value of the concurrency
allowed (I am forgetting the tag name here),
MWS: The concurrentConversations attribute of the ConversationConstraints
element.
This is meant only as an implementation assist to prevent one party from
overloading the other.
MWS: I'm not sure what the CCH problem is. conversationId is the handle
and
its value is stated (in the TRP spec) as an implementation matter. I
suppose
that an implementation could restrict concurrentConversations to limit the
number
of conversation handles but that seems unlikely in this era of Gbyte main
memories.
but that is the main
impact what we have represented has on this problem, that I recall right
this second.
I think that the question of what we as a group would do about
formulating a BSI contract should definitely be a distinct item.
It would be taking on something new, but certainly in line with
promoting
"easier, better, faster, interoperable" b2b integration methods.
MWS: The term "BSI contract" is a little too abstract for me. I believe
that what we (CPPA+BP+MSG) need to define is a software interface
between the legacy application bridge and the top of the BSI and an
abstract interface between the MSH and the rest of the BSI. Is that
what you mean by "contract"? I also believe that these interfaces should
not be
APIs but should describe function and leave the middleware implementers to
define the specific APIs. I understand the counter-argument that a
normative
definition of the interface between the bridge and the BSI will enable
application code to run on everyone's BSI but I don't think that that
argument applies to the BSI-to-MSH interface. I do not expect MSH
implementations
to be sold separately from the whole middleware system.
It is certainly worth raising as a new potential work item either by you
or Karsten or both.
-----Original Message-----
From: Martin W Sachs
Sent: Fri 7/20/2001 8:11 AM
To: Karsten Riemer; ebxml-cppa@lists.oasis-open.org; Dale Moberg
Cc: Stefano POGLIANI; chris.ferris@east.sun.com; Riemer, Karsten
Subject: RE: New work and loose ends
Karsten,
Yes we should have at least an initial discussion next week. I
think it
fits into one of the "loose ends and new function" topics that
are already
on the list to be discussed. If not, bring it up wherever it
seems to fit
in.
Dale, do you think we should fit this in as a separate agenda
item?
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
************************************************************************
*************
Karsten Riemer <Karsten.Riemer@sun.com> on 07/20/2001 09:43:54
AM
Please respond to Karsten Riemer <Karsten.Riemer@sun.com>
To: Stefano POGLIANI <stefano.pogliani@sun.com>
cc: Martin W Sachs/Watson/IBM@IBMUS,
chris.ferris@east.sun.com, "Riemer,
Karsten" <Karsten.Riemer@east.sun.com>
Subject: RE: New work and loose ends
Stefano,
I will let Marty reply about the TRP level, since I am not aware
of what
state
a transport client is expected to keep. I am also copying Chris
Ferris so
he
can comment, too, from a TRP point of view. As to BSI, we were
having
discussions at yesterday's BPSS meeting, and several people,
including Bob
Haugen were asking for you, now that we seem to be ready to
adress BSI
issues.
We will put a 'proposal' for a BSI workgroup to the UN ADHOC
group to be
formed possibly next week, but I really think BSI work should
happen either
in
OASIS (maybe inside CPP team), or at the very least in a joint
OASIS/UN
group,
not in a UN-only group. Marty, can we discuss this in Phoenix
next week?
-karsten
>Marty, Karsten,
>
> just another little topic, perhaps trivial or perhaps not
applicable.
>For this reason I address it ONLY to you two before sending to
the whole
>list.
>If you think it is valid, feel free to express it in plain
english and
>distribute.
>
>I have been thinking since a while to a possible source of
discrepancy
>between the TRP and the CPA.
>
> - The TRP, because of the QoS issues, may be proned to
"keep a state"
> about the exchanged messages.
> The focus of TRP is, though, on THE "message",
independently
> on the fact that this message is actually part of a
choreography
>
> - The CPA gives origin to the BSI. The BSI actually manages
the
> runtime, i.e. the BSI manages the choreography.
> In my opinion, it is likely that the mgmt of the
choreography
> requires the maintenance of a "state" at
choreography-level
> (something, at least, to be able to understand at which
> point in the long-living collaboration the process is in)
>
>Now, keeping these two "state mgmt" stuff separate risks to be
source
>of confusion and inconsistency.
>
>Am I missing something?
>
>Best regards
>
>/stefano
>
>
>> -----Original Message-----
>> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
>> Sent: 19 July 2001 20:37
>> To: ebxml-cppa@lists.oasis-open.org
>> Subject: New work and loose ends
>>
>>
>> I have attached two documents that discuss potential
maintenance and new
>> work items that I will review next week.
>>
>> Regards,
>> Marty
>>
>> (See attached file: CPA-CPP-changes.pdf)List of work items as
of
>> the end of
>> the Vienna ebXML meeting. This includes additional discussion
of
>> some items
>> in the
>> CPPA.new.work document below
>>
>> (See attached file: CPPA.new.work.pdf)Summary of all proposed
work and
>> loose ends as of today. I will be using this as slides next
week.
>>
>>
******************************************************************
>> *******************
>>
>> 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
>>
******************************************************************
>> *******************
>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC