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

["David RR Webber" <david@drrw.info>]

Anders,

I think most companies / transactions use a provisioning
system in any case.

Only the electricity company perhaps works - when you
throw the switch!  And of course they have a meter that
measures the service directly because of that.  Fortunately
there is not flavours of electricity - it is either there or not!

So - there will be some verification step in the process,
where the provider doublechecks that the service is
indeed available - and then they will begin charges.
Example - the telephone company calls a new
customer on their number to verify they have
the service working.

Similarly with delivery of goods.  In services
of the "beam me up now" type - the customer
typically has to pre-pay - before the service
is provided - examples - food.  You do not
want the customer to eat the food and then
pay - except in a resturant of course - because
there you want them to eat more food.

So - I'm seeing BPSS can deliver support
for the necessary accounting verification and
payment for delivery - especially with the
Context Mechanism being able to be used
at the CPA level.  I think that was the piece
we were missing before.

Cheers, DW.

----- Original Message ----- 
From: "Anders W. Tell" <anderst@toolsmiths.se>
To: <ebxml-bp@lists.oasis-open.org>
Sent: Monday, January 12, 2004 9:42 AM
Subject: Re: [ebxml-bp] 12/7/2003: [Fwd: "Late Binding" of TimeToPerform]


> David,
>
> Yes, I can see that we have different views.
>
> What I was trying to convey is that there is a difference beweeen
> * performance (fullfilment) of an obligation in the real world (make a
> service availabe)
> * performance of the obligation to: Notify the opposite party, when the
> service is avilable.
>
> BPSS and CPPA are Notification specifications/agreements which can only
> handle an approximation of real world events through Notices. Of course
> of BPSS is used to perform the delivery then the situation changes,
> rather difficult to invoke "beam me up scotty" as of today.
>
> /anders
>
>
>
>
> David RR Webber wrote:
>
> >Anders,
> >
> >I'm seeing this somewhat differently.
> >
> >There are period of performance constraints.
> >
> >These are specified in the CPA via the Context Mechanism,
> >and agreed to by the parties.
> >
> >This is BEFORE any exchange takes place - so the parties
> >are agreeing to these business criteria.
> >
> >Now as the interchanges occur - the values and the period
> >to perform times are mandated and calculated using the
> >expressions in the Context Mechanism.
> >
> >Whether or not the period to perform is selected such
> >that partners are able to utlize the services in a timely
> >manner is up to them.  If not - then they should adjust
> >the criteria in the Context Mechanism expressions.
> >
> >Thanks, DW.
> >
> >----- Original Message ----- 
> >From: "Anders W. Tell" <anderst@toolsmiths.se>
> >To: <Lars.Abrell@teliasonera.com>
> >Cc: <ebxml-bp@lists.oasis-open.org>
> >Sent: Monday, January 12, 2004 6:44 AM
> >Subject: Re: [ebxml-bp] 12/7/2003: [Fwd: "Late Binding" of TimeToPerform]
> >
> >
> >
> >
> >>Lars,
> >>
> >>You have put the finger on the weakest area of most message oriented
> >>protocols, the difference between Notice semantics and Business, Legal
> >>Semantics. Unless you deliver digital products through BPPS then what
> >>you have is a protocol that deliver Notices about events that are about
> >>to take place or has occured in the real world.
> >>
> >>Notices always comes after real world events and often the party that
> >>has the obligation to deliver also has an obligation to dispatch Notices
> >>before/after real world delivery event, often in resonable time. It
> >>difficult to accuratly define a business rule of delivery date using
> >>Notices, it become an approximation. What is the legal effect of making
> >>a service available to a buyer but not telling the buyer about it? When
> >>can you start to charge the buyer for service availability?
> >>
> >>All in all this why IMO Business Entities and business semantics such as
> >>REA is needed. Thats where the real world, contractual, economic events
> >>semantics and dependencies are defined. Ontop of this you superimpse
> >>Business Dialogs and Notice semantics.
> >>
> >>/anders
> >>
> >>Lars.Abrell@teliasonera.com wrote:
> >>
> >>
> >>
> >>>Monica Martin wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>As for the needs you cite, Anders made an important distinction if you
> >>>>
> >>>>
> >are
> >
> >
> >>>>redirecting the business process or changing the product delivery date
> >>>>that is specified in a business document.  The next question is if
that
> >>>>delivery date changes does it redirect/augment the business process,
and
> >>>>does the business agreement allow for that.  Perhaps we should address
> >>>>this more fully in Monday's meeting.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Just to clarify the use case.
> >>>The "change" in the product delivery data is no actual *change* of the
> >>>
> >>>
> >delivery date for the same instance of a product.
> >
> >
> >>>It is more like different delivery dates for different products or
> >>>
> >>>
> >services ordered in different conversations using the same Binary
> >Collaboration.
> >
> >
> >>>For example in a conversation #1 we order a product A from supplier X
> >>>
> >>>
> >with a delivery date 6 weeks from now. It's OK for us if the order
response
> >telling us that the supplier can execute this order is sent to us after,
let
> >say, one week. I.e. the value in timeToPerform for this simple BC should
be
> >P7D.
> >
> >
> >>>In another conversation #2 (instantiated from the same BC) we order a
> >>>
> >>>
> >service B that needs to be carried out by the same supplier X within 4
> >hours. In this conversation we need to receive an order response telling
us
> >if the supplier is able to carry out the order or not within, let say, 10
> >minutes. Otherwise we might need to engage another supplier. I.e this
time
> >the value in timeToPerform for this same simple BC should be PT10M.
> >
> >
> >>>What I am looking for is the best way of informing our trading partner
> >>>
> >>>
> >(supplier X) and his BSI of the value that should be used in the
> >timeToPerform attribute for each conversation. One way might be to use
the
> >SBDH. Another way could have been using the ebMS message header if the
ebMS
> >spec had provided us with for example a "timeout" attribute in the
> >ConversationID element.
> >
> >
> >>>It would be nice if one were able to specify a time range for the
> >>>
> >>>
> >timeToPerform attribute in the CPPA spec that the trading partners could
> >agree upon should be explicitly specified in runtime. I also think that
if a
> >trading partner is disagreeing with the value given in runtime to the
> >timeToPerform attribute and not able not give a substantive response
before
> >the expiration of the time specified it would be appropriate for him to
send
> >an exception signal instead.
> >
> >
> >>>* 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: Thursday, January 08, 2004 11:22 PM
> >>>To: Abrell, Lars E. /TSS - Networks and Production /031-770 90 80,
> >>>0705-61 90 80
> >>>Cc: ebxml-bp@lists.oasis-open.org
> >>>Subject: Re: [ebxml-bp] 12/7/2003: [Fwd: "Late Binding" of
> >>>TimeToPerform]
> >>>
> >>>
> >>>See comments between ****....****.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Abrell2: It is of course possible to create multiple separate Binary
> >>>>
> >>>>
> >Collaborations that differs only in the timeToPerform value and where the
> >process flow it self is exactly the same. First, IMHO I don't think the
> >timeToPerform value is always an equally "important" business rule to be
> >agreed to and pre-known and determined in the same way as the process
flow
> >it self is. I also believe that this approach could end of with to many
> >Binary Collaborations to handle when you actually only need one.
> >
> >
> >>>>Second, during the Christmas holidays I have read the "UN/CEFACT -
> >>>>
> >>>>
> >Standard Business Document Header Technical Specification Revision 2.1"
> >(http://webster.disa.org/cefact-groups/atg/downloads/index.cfm/). It
seems
> >to me as if this specification specifies the things that I sometimes
think
> >needs to be communicated between trading partners at runtime. I believe
this
> >Standard Business Document Header to some degree overlaps the ebMS spec
and
> >especially the ConversationId, Service, Action and CPAId elements, but at
> >the same time provide me with most (if not all) of the additional
> >information elements I have been missing.
> >
> >
> >>>>The Standard Business Document Header has a "block" called
> >>>>
> >>>>
> >"BusinessScope" that in turn contains a "Service Information" block and a
> >"CorralationInformation" block. This "CorralationInformation" block
contains
> >an element called "ExpectedResponseDateTime" that could be communicated
at
> >runtime between the trading partners and seems to give me what I have
been
> >looking for. See below.
> >
> >
> >>>><BusinessScope>
> >>>><Scope>
> >>>>  <Type>BusinessProcess</Type>
> >>>>     ...
> >>>>     <CorrelationInformation>
> >>>>       ...
> >>>>
> >>>>
> >>>>
> ><ExpectedResponseDateTime>2003-05-10T00:31:52Z</ExpectedResponseDateTime>
> >
> >
> >>>>       ...
> >>>>     </CorrelationInformation>
> >>>></Scope>
> >>>></BusinessScope>
> >>>>
> >>>>The idea and theory around BusinessScope (see appendix 3) look also
very
> >>>>
> >>>>
> >interesting.
> >
> >
> >>>>But I'm somewhat confused about when it's best to communicate the
other
> >>>>
> >>>>
> >BusinessScope kind of information in a Standard Business Document Header
and
> >when to use the elements provided by ebMS.
> >
> >
> >>>>
> >>>>
> >>>>
> >>>>
> >>>****mm2: The SBDH is primarily used to enable enterprise applications
> >>>and legacy systems to be able to access metadata to compile the
business
> >>>document.  That is why the BusinessScope is important.  There has been
> >>>quite a bit of discussion about how this works or overlaps with ebMS,
> >>>and if the SBDH is actually sent with the business document in a
payload
> >>>over the wire to enable parser and translator processing.  As for the
> >>>needs you cite, Anders made an important distinction if you are
> >>>redirecting the business process or changing the product delivery date
> >>>that is specified in a business document.  The next question is if that
> >>>delivery date changes does it redirect/augment the business process,
and
> >>>does the business agreement allow for that.  Perhaps we should address
> >>>this more fully in Monday's meeting.
> >>>
> >>>Dale, could you officiate? Thanks.****
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Kulvantunyou: 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.
> >>>>
> >>>>Abrell: 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.
> >>>>
> >>>>mm1: 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>-- 
> >>/////////////////////////////////////
> >>/ Business Collaboration Toolsmiths /
> >>/ website: <www.toolsmiths.se>      /
> >>/ email: <anderst@toolsmiths.se>    /
> >>/ phone: +46 8 545 885 87           /
> >>/ mobile: +46 70 546 66 03          /
> >>/////////////////////////////////////
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
>
> -- 
> /////////////////////////////////////
> / Business Collaboration Toolsmiths /
> / website: <www.toolsmiths.se>      /
> / email: <anderst@toolsmiths.se>    /
> / phone: +46 8 545 885 87           /
> / mobile: +46 70 546 66 03          /
> /////////////////////////////////////
>
>
>
>