Title: Message

John,

Yes I am trying to have my cake and eat it - by alolowing business people to assert these state-guards.

I'll amend my semantic level expression to thus be in "business logic" -

beginsWhen="product-delivered-date-received AND customer-signature-confirmed"

This is now even better - since this could be two separate transactions - and in the ebContext you create two XPath expressions. Only when both are satisfied - does the beginsWhen state return "true".

Then of course the BT that controlled by that can then initiate the next transaction exchange.

BTW - Its hard to conceive you could get transactions that you were not expecting (ie you had not initiated that BT - but now you get something back anyway - that's into the realms of premonition!).

Although nothing to stop the transport layer using the BPSS state to see if infact that BT is in progress - and then allowing the transaction handling accordingly...

Think this all makes sense now - well to me anyway!

Thanks, DW

----- Original Message ----- From: Yunker, John To: [1]Jean-Jacques Dubray ; [2]mart...@bt.com ; [3]dav...@drrw.info ; [4]Moni...@Sun.COM ; [5]ande...@toolsmiths.se ; [6]naga...@fla.fujitsu.com Cc: [7]ebxm...@lists.oasis-open.org Sent: Tuesday, June 15, 2004 1:14 PM Subject: RE: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract Requirements for State Alignment Close, but not quite...

The beginsWhen expression can be used as both linking to a semantic state (e.g. begins when "state" of "product-delivered" is reached) -and- as a semantic definition that can be used to define that state (e.g. "in the context of this BPSS, "product-delivered" is defined as the existance of both product-delivered-date and delivery-signature")

This could be implemented as either:

1) a filter: the BPSS layer can reject an attempt by the backend integration to start an illegal transaction (and notify of course - up to the implementation in any case) 2) a subscription: the BPSS implementation could link into and use one of those new-fangled semantic-information-maping tools to subscribe to changes in the local implementation of product-delivered-date and delivery-signature.

The important thing is that the BUSINESS COMMUNITY was able to define the semantic business-event controlling the process, so us technology focuessed yahoos would not loose site of our objective. If someone implements a way to use it in an automated fashion, then that's cool -> regardless of whether they are using it for monitoring or execution.

John

-----Original Message----- From: Jean-Jacques Dubray [mailto:jean...@Attachmate.com] Sent: Tuesday, June 15, 2004 10:01 AM To: Yunker, John; mart...@bt.com; dav...@drrw.info; Moni...@Sun.COM; ande...@toolsmiths.se; naga...@fla.fujitsu.com Cc: ebxm...@lists.oasis-open.org Subject: RE: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract Requirements for State Alignment

The key benefit here is the ability to associate/link a BPSS sematic node with both 1) its implementation and 2) its role in the business-agreement/contract layer. How that is implemented with respect to a backend system event is not my concern, what is my concern is the semantic-definition that can be USED to implement a backend monitor.

<JJ>If I understand this paragraph correctly, beginsWhen is not used in the sense of a “guard” (can only begins when the condition is true and other things have to happen before this guard flips its value), but rather in the sense of expressing a state (i.e. when this BTA begins, then we are in the “product delivered state” provided that there is a delivery date,

endsWhen have no influence on the choreography, they are really state representations

</JJ>

-----Original Message----- From: mart...@bt.com [[8]mailto:mart...@bt.com] Sent: Tuesday, June 15, 2004 8:35 AM To: dav...@drrw.info; Moni...@Sun.COM; ande...@toolsmiths.se; Yunker, John; naga...@fla.fujitsu.com; jean...@Attachmate.com Cc: ebxm...@lists.oasis-open.org Subject: RE: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract Requirements for State Alignment

Hi, I know I am not partaking much these days but on this subject I have some views.

beginsWhen and endWhen were effectively comments on the transaction in 1.01 and the CEFACT 1.1. Moving away from this to show some other flow or usage needs to be very, very carefully thought through. I would be unhappy to see that these are used as a back door event based solution. I know that is what they were aimed at originally, it is just that the implications of this are to make the processes more complex.

Martin Roberts xml designer, BT Exact e-mail: mart...@bt.com tel: +44(0) 1473 609785 clickdial fax: +44(0) 1473 609834 Intranet Site :[9]http://twiki.btlabs.bt.co.uk/twiki

-----Original Message----- From: David RR Webber [[10]mailto:dav...@drrw.info] Sent: 15 June 2004 15:29 To: Monica J. Martin; Anders W. Tell; Yunker, John; Kenji Nagahashi; Jean-Jacques Dubray Cc: ebXML BP Subject: Re: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract Requirements for State Alignment

Monica,

Not wanting to preempt discussion on Friday - but just wanting to throw out some technical ideas.

What if we linked the signals to the begins/endsWhen conditionals on a BT?

Just like with my proposal around linkage to context statements using a nameRefID - we could easily point to a named signal (it has that attribute already) and it would be either then boolean true or false. eg: beginsWhen="#mysignal-Is-On"

This still leaves how the signal itself gets set of course! Seems like Dales post earlier may fit / hint into that category...since the only attribute in the signal right now is the URI - how does one actually turn a signal on?!

If we can crack that "glue" then I believe we can provide what we need here.

Am I also right in thinking that essentially used in this way the signals actually constitute the equivalent of an immediate "break" command so familiar in procedural languages to escape into/out of the current logical block. In our case that is of course a BT.

DW

----- Original Message ----- From: "Monica J. Martin" <Moni...@Sun.COM> To: "Anders W. Tell" <ande...@toolsmiths.se>; "Yunker, John" <yun...@amazon.com>; "Kenji Nagahashi" <naga...@fla.fujitsu.com>; "Jean-Jacques Dubray" <jean...@Attachmate.com> Cc: "ebXML BP" <ebxm...@lists.oasis-open.org> Sent: Tuesday, June 15, 2004 1:53 AM Subject: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract Requirements for State Alignment

> Today's ebBP call surrounded how we ensure (as much as practical) > state alignment. Kenji Nagahashi proposed we provide additional > constraints on web services (top-down approach - business process to > web services). We would like to more fully discuss the business > contract requirements related to: State alignment and business > signals. Here are some of the questions that arose (from John Yunker > particularly): > > * How do signals give you state alignment? How do we get certainty > from a business perspective? > * How does the contract layer use the state alignment will help us > relate the special business timeouts to the technical signal > receipt.BPSS provides a semantic to the contract layer. The > business level timeouts in addition to the protocol level have to > be recognized. > * How does the contract layer use the state alignment. This will > help us relate the special business timeouts to the technical > signal receipt. [1] > > The bullets above can form the agenda (subject to team input). Any > member is welcomed to attend. Those expressing an interest today were:

> Yunker, Dubray, Nagahashi and Moberg (and myself). > > You have indicated you would be available Friday and Monday (6/21). > Let's try, as discussed: > > * 877 330 9868, international 909 472 3386, when prompted hit **, > then passcode 09868. > * Time: 9 a.m. PDT, 6 p.m. CET, 18 June 2004. > * Agenda above. > > Thanks. > [1] Steve Capell, RedWahoo question. > > >

References

Visible links 1. jean...@Attachmate.com mailto:jean...@attachmate.com 2. mart...@bt.com mailto:mart...@bt.com 3. dav...@drrw.info mailto:dav...@drrw.info 4. Moni...@Sun.COM mailto:Moni...@sun.com 5. ande...@toolsmiths.se mailto:ande...@toolsmiths.se 6. naga...@fla.fujitsu.com mailto:naga...@fla.fujitsu.com 7. ebxm...@lists.oasis-open.org mailto:ebxm...@lists.oasis-open.org 8. mailto:mart...@bt.com 9. http://twiki.btlabs.bt.co.uk/twiki 10. mailto:dav...@drrw.info