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

[nagahashi@fla.fujitsu.com]

David,

Are you saying CPA has those operational performance parameters?

I believe all the performance parameters specified in the (current)  CPA
and BPSS is for communication performances, i.e. when messaging occurs
(here I agree with Anders). CPA has no way to specify performance
constraint of physical business operation (when products are delivered).
BPSS doesn't either. Communication performance and Business operation
performance sit in the different layers.

So... I agree with you in that "there will be some verification in the
process, where the provider doublechecks that the service is indeed
available," but that's a different kind of service from the service we
are talking here in regard to TimeToPerform.

Sorry if I don't understand your intent.

Regards,
Kenji Nagahashi

"David RR Webber" <david@drrw.info> wroteF
> 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          /
> > /////////////////////////////////////
> >
> >
> >
> >