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

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

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          /
> /////////////////////////////////////
>
>
>
>