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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: RE: more on collaborations, contracts and 2-27 minutes


Stefano,
 
I fully agree with you, plus I like your example of shipping confirmation before getting an order (!); where something like a PO number is your static key.
In business processes where we could have multiple updates of the same PO or multiple inventory updates fo the same item/article number in rapid succession, there's a challenge to keep event reporting between systems in sequence; of course if we could do away with even trying to keep 2 systems in sync and just have the receiver feed right off of the senders inventory database then .. but that's another dicussion and probably a much more interesting too !
 
I do realize ebXML 1.0 can't do everything which is why I think it's important that :
- in general we find a way to sufficiently detail out the open issues, capture them for posterity and submit them into the next ebXML 2.0 development "churn".
- in the interest of group efficiency, the specific directions for ebXML 2.0 be identified as soon as possible, by the responsible party's, for us all.
(O.T.: In my opinion, one of the "secret sauces" that helped ebXML create it's critical mass today is the intimate marriage of technical community developments with business community experiences. Mix with that secret sauce in a bad way, and I'm certain time will show we can blame some of the cooks I saw speak in Vancouver !)
 
In the transaction counting case mentioned, I can reasonably imagine a 'tweek' to deal with the issue in 1.0, but the discussion seems to be something for basic 2.0 business operation functionality.
 
Dave
-----Original Message-----
From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
Sent: Tuesday, March 06, 2001 7:14 AM
To: Welsh, David; James Bryce Clark
Cc: ebxml-bp@lists.ebxml.org; Karsten.Riemer@east.sun.com; linkage@interaccess.com; sharma@netfish.com; Dale_Moberg@stercomm.com; duane@xmlglobal.com
Subject: RE: more on collaborations, contracts and 2-27 minutes

David,
 
    thanks for this mail.
I think that the situations that will be modelled are different one the other. In your case, the ordering is (as I have well understood) across the transactions (well, it all depends on how the sitatuion is modelled, after all).
I had in mind a more simple situation where within the same Collaboration, there are many messages; in some way I cannot receive a confirmation of shipment before having received the order itself.
 
Whilst in your situation the application should play a more important role in the verification process (I think that the kind of verification you describe cannot be done by the middleware but is actually "legacy application" dependent since it is the legacy which has the knowledge of the sequencing), in my situation the middleware is the one responsible for verifying the correct sequencing of messages within the same BP instance.
 
Best regards
 
/stefano
-----Original Message-----
From: Welsh, David [mailto:David.Welsh@nordstrom.com]
Sent: 06 March 2001 15:45
To: 'stefano.pogliani@sun.com'; James Bryce Clark
Cc: ebxml-bp@lists.ebxml.org; Karsten.Riemer@east.sun.com; linkage@interaccess.com; sharma@netfish.com; Dale_Moberg@stercomm.com; duane@xmlglobal.com
Subject: RE: more on collaborations, contracts and 2-27 minutes

Stefano,
There's probably a few different use cases for 'sequential counting' , but one of them that is really a sort of 'crude EDI 101' is where one company's applications (in a binary relationship) try's to do a reasonable business control by itself to look for sequential number sequencing from the sender's applications; cause who say's it's a perfect world.
I've regularily seen this type of thing happen often, especially in situations as an example where a warehouse is sending a logistics planning system it inventory database adjustments (increment/decrement on-hand) and to make sure the systems are in as much sync as possible the receiver application itself imposes sequential numbering on the sender application itself.
If those inventory adjust records get inadvertantly posted (just once) in the wrong order at the receivers end then literally "millions of dollars of damage" can occur; and it ain't easy to undo (trust me if you've ever dealt with company auditors).
 
I think you're right there needs to be "a correct sequencing" service going on by a "middleware" as the 'transactions come flying by' but middleware usually can't determine the complete correct logical context of a transaction being sent, before it's posted at the receivers side in it's database, so we sometimes have to help the receiver applications.
 
Dave
 
-----Original Message-----
From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
Sent: Tuesday, March 06, 2001 1:16 AM
To: James Bryce Clark; Welsh, David
Cc: ebxml-bp@lists.ebxml.org; Karsten.Riemer@east.sun.com; linkage@interaccess.com; sharma@netfish.com; Dale_Moberg@stercomm.com; duane@xmlglobal.com
Subject: RE: more on collaborations, contracts and 2-27 minutes

Hope not to miss the point completely.... in which case I apologize.
 
The verification of the correct sequencing should be done by the middleware (the infamous BSI) which should be configured out of the content of the CPA (which, in turn, references the Collaboration choreography specified by the BP).
 
/stefano
-----Original Message-----
From: James Bryce Clark [mailto:jbc@lawyer.com]
Sent: 05 March 2001 22:05
To: Welsh, David
Cc: 'James Bryce Clark'; ebxml-bp@lists.ebxml.org; Karsten.Riemer@east.sun.com; linkage@interaccess.com; sharma@netfish.com; Dale_Moberg@stercomm.com; duane@xmlglobal.com
Subject: RE: more on collaborations, contracts and 2-27 minutes

Dave asks for confirmation that something in ebXML can tag and count messages sequentially, so as to enable crossreferencing, detection of blips arriving out of sequence, and the like:

 "I can understand that at a lower level TRP service, there's something dealing with 'message counting' but I'm not aware that something like this info finds it's way up the stack so the business app's can also do their counting; which does sound like redundant but it is the way of the world and as such it's not going to stop. "

In our "simple negotiation pattern" test, we also noted that messages need to be able to cross reference each other, and sought confirmation of some kind of unique message ID.

Good questions.  I don't know the answer.   Can we do that?   Goes on my list for tomorrow's metamodel meeting.   Jamie

James Bryce Clark
Spolin Silverman & Cohen LLP
310 586 2404    jbc@lawyer.com   

James Bryce Clark
Spolin Silverman & Cohen LLP
310 586 2404    jbc@lawyer.com   


[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