RE: New work and loose ends

[Dale Moberg <dmoberg@cyclonecommerce.com>]

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? 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.
 
The CCH problem is possibly "flavored" by the value of the concurrency
allowed
(I am forgetting the tag name here), 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.
 
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
	>>
******************************************************************
	>> *******************
	>>

winmail.dat