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] | [List Home]


Subject: Re: [ebxml-bp] 12/7/2003: [Fwd: "Late Binding" of TimeToPerform]


I am not sure if I understand the whole complexity of the issue or not. I
preferred the BPSS being declarative at design time of business rule b/c 1)
business rules are captured declaratively and 2) it supports the advance
dynamic binding b/w partners. So my thought for the use case described by
Lars is to create multiple Binary Collaborations with different
timeToPerform's for both BC and BTA for different classes of
products/services rather than overriding at the runtime.

I'm not sure whether the BPSS (I mean specifically BC) is supposed to be
context specific or context indenpendent according to the Architecture. My
thought is that it is context specific.

- serm

----- Original Message ----- 
From: <Lars.Abrell@teliasonera.com>
To: <Monica.Martin@Sun.COM>; <ebxml-bp@lists.oasis-open.org>
Sent: Wednesday, December 10, 2003 7:19 PM
Subject: RE: [ebxml-bp] 12/7/2003: [Fwd: "Late Binding" of TimeToPerform]


Hi,
I have compiled a short summary proposal for Work Item 55 about the late
binding of the timeToPerform attribute. This is my very first proposal and
I'm not sure if this is sufficient, but I hope so. There are still several
implications and other things that needs to be worked out, and it would be
very interesting also to listen to other opinions.

* Lars.Abrell@TeliaSonera.com * +46 (0) 705 619080
* Kilsgatan 4, Box 299, SE-401 24 Gothenburg, Sweden



-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
Sent: Sunday, December 07, 2003 10:26 PM
To: ebXML BP
Subject: [ebxml-bp] 12/7/2003: [Fwd: "Late Binding" of TimeToPerform]


Lars, after reviewing the slides, the note and thinking about the learning
session and teleconference discussions, there are several items that we
should perhaps address, and talk about in the context of BPSS:

    * Late binding on the BPSS
          o Specifying the timeToPerform to the greatest time possible in
the context of this type of collaboration [1]
                + Allowing late binding to accommodate logical business
document requirements
                + Specifying when the late binding may occ
    * Potential to override BPSS attributes in the CPP/A between the parties
[2] [3]
    * Breaking the response into multiple responses: where more timing
applies to specific requirements (such as delivery)
or either from the perspective of the requestor or the responder [4]

I encourage the team to think about these items in the context of
roles/partners, timeToPerform, and the dynamic aspects of late binding
we discussed last week. [5]

[1] May likely not be as tight you would like given the interactions defined
by internal systems to support. Which brings up an interesting point on
being able to keep these systems loosely coupled. For example, we have one
case where the order may go by alternate means and not logged in the B2B
system, and this really complicates this company's processing. We have to
account for that at the process level.
[1] Determine if this could meet your needs: See Section 9 of CPP/A
document.
[3] May complement any late binding functionality if adopted.
[4] This may be driven either by business or service level agreements, or on
a case by case basis. For the latter, I would think we will have to discuss
the per-instance impact and its appropriateness.
[5] Related Work Items 23, 25, 28, 46 and 55.

-------- Original Message --------
Subject: "Late Binding" of TimeToPerform
Date: Wed, 03 Dec 2003 03:21:23 +0100
From: Lars.Abrell@teliasonera.com
To: Monica.Martin@Sun.COM



Monica,
During our use of BPSS we have in different situations noticed a need for
different values in the TimeToPerform attribute for the same Binary
Collaboration. This specific use case is based on the BC:NegotiateOrder in
the NeBI specification (www.nebi.biz). Please see the attached slides. This
very simple use case for ordering different "Field Service Products" in the
telecom industry is based on using only the BTA:OrderRequestByBuyer and the
BTA:OrderAcknowledgmentBySupplier in the BC:NegotiateOrder. This simple
version of the BC:NegotiateOrder is used for ordering different products
using the same generic BusinessDocument (BD:Order). In the product specific
part of this BD:Order (i.e, in the order rows) the different "Field Service
Products" are specified. Depending on the different "Field Service Products"
(or combinations of  "Field Service Products") in a BD:Order or different
"time to delivery" of the specified product, there is a need also to have
different values in the TimeToPerform attribute of the BC:NegotiateOrder.

Feel free to use this in any way you think is appropriate

 <<TimeToPerform.ppt>>
Regards //Lars
Lars Abrell, TeliaSonera






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